Re: EPEL xsensor GUI Failed, any bug reports?
You sent this yesterday as well, and it was politely ignored, as it's not really a question for this list. Bugzilla was working fine yesterday. It's working today as well. Please check and fix your network connection. On 06/11/2014 02:52 PM, ToddAndMargo wrote: Hi, Scientific Linux 6.5, 64 bit I can not get Red Hat's bugzilla to work (502 proxy error). Does anyone know is there is a bug report against xsensors for GUI Failed? $ uname -r 2.6.32-431.17.1.el6.x86_64 $ rpm -qa xsensors xsensors-0.73-1.el6.x86_64 Many thanks, -T ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel -- Jim Perrin The CentOS Project | http://www.centos.org twitter: @BitIntegrity | GPG Key: FA09AD77 ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
EPEL Fedora 5 updates-testing report
The following Fedora EPEL 5 Security updates need testing: Age URL 781 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2012-5630/bugzilla-3.2.10-5.el5 235 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2013-11893/libguestfs-1.20.12-1.el5 115 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-0581/augeas-1.2.0-1.el5 14 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-1515/check-mk-1.2.4p2-2.el5 11 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-1544/python26-mod_wsgi-3.5-1.el5,mod_wsgi-3.5-1.el5 6 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-1575/chkrootkit-0.49-9.el5 0 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-1626/puppet-2.7.26-1.el5 The following builds have been pushed to Fedora EPEL 5 updates-testing pidgin-sipe-1.18.2-1.el5 puppet-2.7.26-1.el5 qfaxreader-0.3.2-2.el5 shellinabox-2.14-27.git88822c1.el5 Details about builds: pidgin-sipe-1.18.2-1.el5 (FEDORA-EPEL-2014-1599) Pidgin protocol plugin to connect to MS Office Communicator Update Information: New upstream release: * adds support for EWS Autodiscover redirection * fixes false not delivered errors in conference * fixes incorrect HTML escaping for URLs * fixes endless loop with failed HTTP Basic authentication * fixes missing Copy to in buddy menu * fixes crash when PersistentChat sends BYE * fixes joining of conference for some users * fixes conference call ending in error message * fixes EWS autodiscover for some Office 365 users * UCS now honors email URL set by user ChangeLog: * Sat Jun 7 2014 Stefan Becker chemob...@gmail.com - 1.18.2-1 - update to 1.18.2: - fixes crash when PersistentChat sends BYE - fixes joining of conference for some users - fixes conference call ending in error message - fixes EWS autodiscover for some Office 365 users - UCS now honors email URL set by user * Sat Apr 12 2014 Stefan Becker chemob...@gmail.com - 1.18.1-1 - update to 1.18.1: - fixes false not delivered errors in conference - fixes incorrect HTML escaping for URLs - fixes endless loop with failed HTTP Basic authentication - fixes EWS autodiscover for some Office 365 users - fixes missing Copy to in buddy menu * Sat Jan 11 2014 Stefan Becker chemob...@gmail.com - 1.18.0-1 - update to 1.18.0: - added support for EWS Autodiscover redirection puppet-2.7.26-1.el5 (FEDORA-EPEL-2014-1626) A network tool for managing many disparate systems Update Information: Update to 2.7.26 to mitigate CVE-2014-3248 ChangeLog: * Wed Jun 11 2014 Sam Kottler skott...@fedoraproject.org - 2.7.26-1 - Update to 2.7.26 to mitigate CVE-2014-3284 * Wed Jan 8 2014 Todd Zullinger t...@pobox.com - 2.7.25-2 - Fix NetworkManager dispatcher.d installation (#1050139) qfaxreader-0.3.2-2.el5 (FEDORA-EPEL-2014-1625) A multipage monochrome/color TIFF/FAX viewer Update Information: new upstream version shellinabox-2.14-27.git88822c1.el5 (FEDORA-EPEL-2014-1610) Web based AJAX terminal emulator Update Information: Add additional SSH option ProxyCommand=none to hard-coded defaults ChangeLog: * Wed Jun 11 2014 Simone Caronni negativ...@gmail.com - 2.14-27.git88822c1 - Add additional ssh option ProxyCommand=none (#1013974). * Sun Jun 8 2014 Fedora Release Engineering rel-...@lists.fedoraproject.org - 2.14-26.git88822c1 - Rebuilt for https://fedoraproject.org/wiki/Fedora_21_Mass_Rebuild * Tue Aug 6 2013 Simone Caronni negativ...@gmail.com - 2.14-25.git88822c1 - Add systemd to BuildRequires; not default on Fedora 20+. - Remove Fedora 17 conditionals, distribution EOL. - Remove systemd-sysv dependency as per new packaging guidelines. * Sun Aug 4 2013 Fedora Release Engineering rel-...@lists.fedoraproject.org - 2.14-25.git88822c1 - Rebuilt for https://fedoraproject.org/wiki/Fedora_20_Mass_Rebuild
[Bug 1106265] perl-Twiggy: FTBFS in rawhide
https://bugzilla.redhat.com/show_bug.cgi?id=1106265 Robin Lee robinlee.s...@gmail.com changed: What|Removed |Added Status|NEW |CLOSED Fixed In Version||perl-Twiggy-0.1024-2.fc21 Resolution|--- |RAWHIDE Last Closed||2014-06-11 02:21:37 -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=n2dCn5YpO5a=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: help needed to find a bug in zorba (or gcc 4.9)
On 10.6.2014 21:47, Martin Gieseking wrote: Am 10.06.2014 20:44, schrieb Jerry James: Here's the first problem pointed out by valgrind: - class Store (src/store/naive/store.h) has a public member zstring theEmptyNs - that object is set to a string that is also added to StringPool *theNamespacePool inside Store::init() (src/store/naive/store.cpp) - when the ZorbaImpl destructor runs on the singleton ZorbaImpl object, it starts this call chain: o shutdownInternal(false) o StoreManager::shutdownStore(GENV_STORE) o SimpleStore::shutdown(false) o Store::shutdown(false) - Since theNamespacePool is non-NULL, we do this: theEmptyNs.~zstring(); theXmlSchemaNs.~zstring(); delete theNamespacePool; theNamespacePool = NULL; We deleted theEmptyNs ... but left it sitting in theNamespacePool. So when theNamespacePool's destructor runs, it examines that string, leading to the crash. The same thing happens with theXmlSchemaNs. The fix is to remove those strings from the StringPool instead of explicitly deallocating them, and then let the Store destructor actually delete the two strings, like so: Jerry, thank you for taking the time to look into the code and for tracking down the first issue. However, it's the same one I already fixed with patch 4 (zorba-namespace-pool.patch) present in the latest SRPM [1] linked in my initial email. It has also been applied upstream already. Unfortunately, it appears that that is not the only bug. Valgrind shows at least two more bugs, both also tied into SimpleStore and Store somehow, but I'm out of time to look at them. Yes, the remaining bugs are hard to isolate. They always occur in conjunction with the zstring/rstring objects. I just can't find the location where the memory gets corrupted so that the access to their data fields fail... Maybe you can try Valgrind gdbserver: http://valgrind.org/docs/manual/manual-core-adv.html#manual-core-adv.gdbserver-concept I'm sorry if you already tried that :-) Petr^2 Spacek Off topic: the check for unicode/coll.h (ZORBA_HAVE_COLL_H) is failing spuriously because CHECK_INCLUDE_FILES is used where CHECK_INCLUDE_FILE_CXX should be used. One fix is to do this in %prep: # Fix detection of unicode/coll.h sed -i 's,\(CHECK_INCLUDE_FILE\)S\( (unicode/coll.h\),\1_CXX\2,' CMakeLists.txt Also thank you for this hint. I'm going to add the fix the bug and report it upstream. Martin [1] http://mgieseki.fedorapeople.org/review/zorba-3.0.0-4.fc21.src.rpm -- 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: Save everybody some surprises in Fedora 22!
On 06/07/2014 10:55 PM, Garry T. Williams wrote: On 6-6-14 14:46:23 Ales Kozumplik wrote: We're wondering: is there stuff people are still missing from DNF The --advisory option. Building updateinfo support is underway: https://bugzilla.redhat.com/show_bug.cgi?id=850912 Ales -- 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: Improving the state of ARM
While I certainly think clang should be fixed on ARM, it's important to note: * clang doesn't work on i686/x86_64 either *[1] In both cases you have to hack the standard RPM flags, otherwise compilation fails. Therefore all arguments about ARM being dropped as a primary architecture for not supporting clang, apply equally to x86. For the supported compilers, ARM is equivalent to x86. Rich. [1] https://bugzilla.redhat.com/show_bug.cgi?id=1099282#c2 -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into KVM guests. http://libguestfs.org/virt-v2v -- 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: NetworkManager-0.9.95 update in rawhide
On Tue, Jun 10, 2014 at 11:19 PM, Dan Williams d...@redhat.com wrote: On Tue, 2014-06-10 at 21:37 +0400, Igor Gnatenko wrote: On Tue, Jun 10, 2014 at 9:34 PM, Thomas Haller thal...@redhat.com wrote: On Tue, 2014-06-10 at 21:25 +0400, Igor Gnatenko wrote: Hi, After latest update i can't use my wifi in NM. Probably this bug not in NM, but I don't know how to debug this :( Do you have the package NetworkManager-wifi installed? no. Interesting. Check with $ yum list NetworkManager-wifi and you certainly need it. Actually, you should have gotten it automatically... What's happens? Checking dnf logs. As Igor and I discussed on IRC, the new NetworkManager package and sub-packages include Obsoletes: NetworkManager 1:0.9.9.95-1 which should cause *all* the subpackages (including NetworkManager-wifi) to replace the previous packages, and thus NM-wifi should be installed. We're checking with dnf people to figure out why this doesn't seem to be the case. I tested with 'yum' and a local repo before building the F21 update and this worked correctly, so at the moment the issue seems to be with dnf. https://bugzilla.redhat.com/show_bug.cgi?id=1107973 Dan -- -Igor Gnatenko -- 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: [fedora-arm] ExcludeArch tracker doesn't appear to be effective
On Tue, Jun 10, 2014 at 09:32:54PM +0100, Matthew Garrett wrote: I don't think the current state of the ARM port is good enough. Are you actually using the ARM ports? I'm using the 32 bit ARM primary on two machines and the aarch64 secondary on a third, and they work well. If there are specific packages which don't work for you, then please let us know. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into KVM guests. http://libguestfs.org/virt-v2v -- 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: [fedora-arm] ExcludeArch tracker doesn't appear to be effective
On Wed, Jun 11, 2014 at 12:07:23AM +0200, drago01 wrote: On Tue, Jun 10, 2014 at 11:52 PM, Peter Robinson pbrobin...@gmail.com wrote: [...] So moving on from that why don't you feel comfortable pointing to the ARM port? The question wasn't really directed at me but adding my 2 cents ... basically on x86(_64) hardware I can point people at fedora and most of the time it will work. As for ARM if you get a random arm hardware chances are that it is simply not supported or needs some manual hacks to get used. That's not really a fedora specific problem but it makes ARM more of a gimmick to me ... until hardware vendors catch up. As you say, mostly this is the nature of the platform. 32 bit ARM hardware is not self-describing, and not at all uniform (unlike PCs). There is no BIOS. There's no standard text display or serial port. This ought to improve greatly with 64 bit ARM, where Red Hat are pushing for everything to support UEFI booting and ACPI for hardware description. A single upstream open source kernel should [eventually] be able to boot on every aarch64 machine, even ones that have not been seen before. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://people.redhat.com/~rjones/virt-top -- 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: ExcludeArch tracker doesn't appear to be effective
On 10/06/14 19:28, Matthew Garrett wrote: Fedora is supposed to provide a consistent experience across primary architectures. Having a subset of our packages fail to build on ARM means that's not true, and the current state of affairs clearly violates point 8 of the architecture promotion requirements. Fedora includes a lot of packages, some of which are not of mainstream interest. Because of this lack of interest in their packages, some upstream maintainers haven't ported to ARM. Some upstream packages may not even still be actively maintained. How can we fix this? We have to look at this on a case-by-case basis. We might have to ask if a package really is relevant to a general-purpose operating system. [Some packages may have been abandoned upstream. So, they will never be ported to ARM.] Let's look at Bug 1004357 - root no available on ARM due to cint. The upstream maintainers say: We will not implement vararg support for that platform in ROOT 5. It's not trivial and we have to spend our time getting ROOT 6 baked. Thanks for your understanding! So, what should we do? Should we block Fedora from running on ARM because of the lack of upstream support for the ROOT numerical data analysis framework? No! That would be ridiculous. It would mean that Fedora on the ARM target is held hostage by this package. Special-purpose packages are all well and good, but Fedora on ARM is (IMHO, YMMV) far more important than those packages. Andrew. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
EPEL epel beta report: 20140611 changes
Compose started at Wed Jun 11 08:15:02 UTC 2014 New package: mingw-gmp-5.1.1-3.el7 Cross-compiled GNU arbitrary precision library New package: mingw-gnutls-3.3.2-2.el7 MinGW GnuTLS TLS/SSL encryption library New package: mingw-gstreamer1-plugins-base-1.3.2-1.el7 Cross compiled GStreamer1 media framework base plug-ins New package: mingw-libwebp-0.2.1-2.el7 MinGW compilation of Library and tools for the WebP format New package: mingw-nettle-2.7.1-2.el7 MinGW package for nettle cryptographic library New package: mingw-postgresql-9.3.4-2.el7 MinGW Windows PostgreSQL library New package: mingw-qt-4.8.6-3.el7 Qt for Windows New package: mingw-qt5-qtbase-5.3.0-2.el7 Qt5 for Windows - QtBase component New package: mingw-qt5-qtgraphicaleffects-5.3.0-2.el7 Qt5 for Windows - QtGraphicalEffects component New package: mingw-qt5-qtimageformats-5.3.0-2.el7 Qt5 for Windows - QtImageFormats component New package: mingw-qt5-qtscript-5.3.0-2.el7 Qt5 for Windows - QtScript component New package: mingw-qt5-qtsvg-5.3.0-2.el7 Qt5 for Windows - QtSvg component New package: mingw-qt5-qttools-5.3.0-0.el7 Qt5 for Windows - QtTools component New package: mingw-qt5-qttranslations-5.3.0-1.el7 Qt5 for Windows - QtTranslations component New package: mingw-tcl-8.5.15-2.el7 MinGW Windows Tool Command Language, pronounced tickle New package: oz-0.12.0-2.el7 Library and utilities for automated guest OS installs New package: python-catkin_tools-0.1.0-1.el7 Command line tools for working with catkin Updated Packages: mingw-win-iconv-0.0.6-1.el7 --- * Wed May 28 2014 Erik van Pienbroek epien...@fedoraproject.org - 0.0.6-1 - Update to 0.0.6 * Sat Aug 03 2013 Fedora Release Engineering rel-...@lists.fedoraproject.org - 0.0.4-3 - Rebuilt for https://fedoraproject.org/wiki/Fedora_20_Mass_Rebuild phoronix-test-suite-5.2.0-1.el7 --- * Tue Jun 10 2014 Markus Mayer lotharl...@gmx.de - 5.2.0-1 - new upstream release * Sat Jun 07 2014 Fedora Release Engineering rel-...@lists.fedoraproject.org - 5.0.1-2 - Rebuilt for https://fedoraproject.org/wiki/Fedora_21_Mass_Rebuild php-horde-Horde-Image-2.0.9-1.el7 - * Tue Jun 10 2014 Remi Collet r...@fedoraproject.org - 2.0.9-1 - Update to 2.0.9 php-horde-Horde-Ldap-2.1.0-1.el7 * Tue Jun 10 2014 Remi Collet r...@fedoraproject.org - 2.1.0-1 - Update to 2.1.0 php-horde-Horde-ListHeaders-1.1.3-1.el7 --- * Tue Jun 10 2014 Remi Collet r...@fedoraproject.org - 1.1.3-1 - Update to 1.1.3 - regenerate locales during build php-horde-Horde-Smtp-1.5.1-1.el7 * Tue Jun 10 2014 Remi Collet r...@fedoraproject.org - 1.5.1-1 - Update to 1.5.1 Summary: Added Packages: 17 Removed Packages: 0 Modified Packages: 6 ___ epel-devel mailing list epel-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
Re: Qt packages necessaries to develop for Android
On Tue, Jun 10, 2014 at 5:49 PM, Kevin Kofler kevin.kof...@chello.at wrote: Hunting for patents is one thing (I wouldn't recommend it either), but looking for obviously patent-encumbered stuff (like MP3 codecs) is another . Unfortunately it is generally not obvious what things are obviously patent-encumbered. -- 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: help needed to find a bug in zorba (or gcc 4.9)
Am 11.06.2014 08:32, schrieb Petr Spacek: Unfortunately, it appears that that is not the only bug. Valgrind shows at least two more bugs, both also tied into SimpleStore and Store somehow, but I'm out of time to look at them. Yes, the remaining bugs are hard to isolate. They always occur in conjunction with the zstring/rstring objects. I just can't find the location where the memory gets corrupted so that the access to their data fields fail... Maybe you can try Valgrind gdbserver: http://valgrind.org/docs/manual/manual-core-adv.html#manual-core-adv.gdbserver-concept I'm sorry if you already tried that :-) Thanks, Petr. Yes, I already tried that too, but without much success so far. Martin -- 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: Improving the state of ARM
On Wed, 2014-06-11 at 08:48 +0100, Richard W.M. Jones wrote: While I certainly think clang should be fixed on ARM, it's important to note: * clang doesn't work on i686/x86_64 either *[1] Just a reminder, while the llvm package is nominally mine, my interest in it extends exactly as far as llvm, and even that is grudging. That clang is built from the same srpm is only because llvm upstream don't give you any other way to build it, afaik (and if this changes I will happily fix the packaging to reflect it). I am happy to have comaintainers. Honestly I'd mark it cvsextras+ if that was still a thing we had. In both cases you have to hack the standard RPM flags, otherwise compilation fails. Therefore all arguments about ARM being dropped as a primary architecture for not supporting clang, apply equally to x86. Except that on x86, if you hack out -fstack-protector-strong, floating point code will compile and link, where on arm it will not even get as far as compiling. - ajax -- 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: rawhide report: 20140611 changes
Hi John, ptpd-2.3.0-2.fc21 - * Tue Jun 10 2014 Jon Kent - 2.3.0-2 - restricted Arch to i686 and x86_64 * Sun Jun 08 2014 Jon Kent - 2.3.0-1 - Updates to ptpd 2.3.0 I'm wondering why you've restricted ptpd to just x86? It builds fine on all the other architectures (I tested arm,aarch64,ppc64,s390x) [2-5] and I don't see any bugs reported for the other architectures as per packaging guidelines [1] as to any other reason this package would be excluded from the other architectures. We have NICs that support this functionality at least on ARM. Peter [1] http://fedoraproject.org/wiki/Packaging:Guidelines#Architecture_Support [2] http://koji.fedoraproject.org/koji/taskinfo?taskID=7035607 [3] http://arm.koji.fedoraproject.org/koji/taskinfo?taskID=2397644 [4] http://ppc.koji.fedoraproject.org/koji/taskinfo?taskID=1883234 [5] http://s390.koji.fedoraproject.org/koji/taskinfo?taskID=1427320 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
F22 System Wide Change: Replace Yum With DNF
= Proposed System Wide Change: Replace Yum With DNF = https://fedoraproject.org/wiki/Changes/ReplaceYumWithDNF Note: This is Fedora 22 proposal! Change owner(s): Aleš Kozumplík kozump...@gmail.com Make DNF/Yum4 the new default packaging tool in F22. == Detailed Description == DNF was forked from Yum in January 2012 and available for experimenting in Fedora since release 18 [1]. The project is now fully capable of replacing Yum in new Fedora installations. We want DNF to become the new default packaging tool in Fedora 22. This entails: * letting system administrators (including users who routinely manage their packages using the legacy Yum) perform all common packaging operations using DNF, with no or minimal and documented [2] change to the command syntax, apart from replacing the command name. (done) * providing implementation of Anaconda backend so system can be bootstrapped completely without using legacy Yum. (done) * providing alternative to all Yum plugins from yum-utils (ongoing) * providing alternative to all release engineering tools (repoquery, bodhi etc.) from yum-utils (ongoing) * being ready/having the capacity to help out users with migration of their custom legacy plugins and extensions to DNF. The solid API documentation [3] we provide is of great advantage here. (ongoing) In practice, the change implies: * Anaconda installs the system using the DNF backend (with no special switches) * package 'dnf' is installed by default (referenced by the base comps groups) * package 'dnf-yum-compat-command' is installed by default. It obsoletes Yum and provides its own code/usr/bin/yum/code, a short script that redirects to code/usr/bin/dnf/code with an appropriate warning message that DNF is the preferred package manager now. Notice that upgrading F21 to F22 will not cause the compat package to be installed so will not disturb any upgrading users. == Scope == This change will be completely transparent for users that use only the graphical package management tools. For anybody using the command line directly there will be some differences, but all the important operations are available with DNF, using the same CLI syntax. * Proposal owners: The majority of tasks on this change are completed. Some plugins and API calls still need to be added. The Anaconda payload implementation needs more testing, Fedora Test Day for this is pending. * Other developers: We provide the paylaod implementation for Anaconda developers. Developers of other extensions and developers of plugins that are not part of yum-utils will have to update their code. * Release engineering: Release engineering tools that are internal to the releng teams and not part of yum-utils will need modifications to migrate to the DNF API. * Policies and guidelines: None at the moment. [1] https://fedoraproject.org/wiki/Features/DNF [2] http://akozumpl.github.io/dnf/cli_vs_yum.html [3] http://akozumpl.github.io/dnf/api.html ___ devel-announce mailing list devel-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel-announce -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
[Bug 1108091] New: perl-CGI-4.02 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1108091 Bug ID: 1108091 Summary: perl-CGI-4.02 is available Product: Fedora Version: rawhide Component: perl-CGI Keywords: FutureFeature, Triaged Assignee: jples...@redhat.com Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: jples...@redhat.com, perl-de...@lists.fedoraproject.org Latest upstream release: 4.02 Current version/release in Fedora Rawhide: 4.01-2.fc21 URL: http://search.cpan.org/dist/CGI/ Please consult the package updates policy before you issue an update to a stable branch: https://fedoraproject.org/wiki/Updates_Policy More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=JU6Xp7ikvga=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 1108093] New: perl-CPANPLUS-0.9152 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1108093 Bug ID: 1108093 Summary: perl-CPANPLUS-0.9152 is available Product: Fedora Version: rawhide Component: perl-CPANPLUS Keywords: FutureFeature, Triaged Assignee: ppi...@redhat.com Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: perl-de...@lists.fedoraproject.org, ppi...@redhat.com Latest upstream release: 0.9152 Current version/release in Fedora Rawhide: 0.91.48-2.fc21 URL: http://search.cpan.org/dist/CPANPLUS/ Please consult the package updates policy before you issue an update to a stable branch: https://fedoraproject.org/wiki/Updates_Policy More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=GJ2ZMUBFq3a=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 1108094] New: perl-Date-Easter-1.21 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1108094 Bug ID: 1108094 Summary: perl-Date-Easter-1.21 is available Product: Fedora Version: rawhide Component: perl-Date-Easter Keywords: FutureFeature, Triaged Assignee: dd...@cpan.org Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: dd...@cpan.org, perl-de...@lists.fedoraproject.org Latest upstream release: 1.21 Current version/release in Fedora Rawhide: 1.20-2.fc21 URL: http://search.cpan.org/dist/Date-Easter/ Please consult the package updates policy before you issue an update to a stable branch: https://fedoraproject.org/wiki/Updates_Policy More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=AIZxsTqoZ5a=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: F22 System Wide Change: Replace Yum With DNF
On Wed, Jun 11, 2014 at 02:44:10PM +0200, Jaroslav Reznik wrote: * package 'dnf-yum-compat-command' is installed by default. It obsoletes Yum and provides its own code/usr/bin/yum/code, a short script that redirects to code/usr/bin/dnf/code with an appropriate warning message that DNF is the preferred package manager now. Notice that upgrading F21 to F22 will not cause the compat package to be installed so will not disturb any upgrading users. This is kind of sentimental, and I think possibly Seth would not have liked to have a big deal made of it, but... I guess I'm going to anyway. I would like to keep the yum name in remembrance of his contributions. This also seems like the easiest path for all of the documentation, scripts, and user habits out there. I don't mind if the backend package is called dnf, but why not keep /usr/bin/yum as the primary command and just do the right thing, only warning on incompatible usage rather than nagging every time it is used? -- Matthew Miller mat...@fedoraproject.org Fedora Project Leader -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
[Bug 999033] perl-Regexp-Grammars-1.034 is available
https://bugzilla.redhat.com/show_bug.cgi?id=999033 Upstream Release Monitoring upstream-release-monitor...@fedoraproject.org changed: What|Removed |Added Summary|perl-Regexp-Grammars-1.033 |perl-Regexp-Grammars-1.034 |is available|is available --- Comment #2 from Upstream Release Monitoring upstream-release-monitor...@fedoraproject.org --- Latest upstream release: 1.034 Current version/release in Fedora Rawhide: 1.033-2.fc21 URL: http://search.cpan.org/dist/Regexp-Grammars/ Please consult the package updates policy before you issue an update to a stable branch: https://fedoraproject.org/wiki/Updates_Policy More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=qieZaITi6Ta=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: ssh problem with pkgs.fedoraproject.org
I too am now seeing exactly this problem I'll email Kevin my IP address too... unless there's a more generic infra email address I should send to? On 7 June 2014 19:31, Kevin Fenzi ke...@scrye.com wrote: On Sat, 7 Jun 2014 12:24:42 -0600 Jerry James loganje...@gmail.com wrote: I can't do a git pull on my packages from home anymore. The heart of the problem is this: ...snip... This started recently, just a few weeks ago. Before that, I was able to do git operations from home with no problem. Is pkgs.fedoraproject.org running denyhosts? If not, any other ideas? i'm stumped. It is running denyhosts. Can you send me a email off list with your home IP address and I can check denyhosts... kevin -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- 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: F22 System Wide Change: Replace Yum With DNF
Hi On Wed, Jun 11, 2014 at 8:52 AM, Matthew Miller wrote: This is kind of sentimental, and I think possibly Seth would not have liked to have a big deal made of it, but... I guess I'm going to anyway. I would like to keep the yum name in remembrance of his contributions. This also seems like the easiest path for all of the documentation, scripts, and user habits out there. I don't mind if the backend package is called dnf, but why not keep /usr/bin/yum as the primary command and just do the right thing, only warning on incompatible usage rather than nagging every time it is used? I strongly agree with this for practical reasons. There is no good rationale for moving away from yum as the name of the command except some of the command line changes which happened with yum anyway (download only was added and later removed for example) and one can warn specifically for those. The API changes are not something users care about. Also, dnf needs to drop all the legacy options before the transition (ie) pick erase or remove (preferably the latter) etc rather than retain all the compatibility options. Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
[Bug 1108107] New: perl-Text-CSV_XS-1.09 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1108107 Bug ID: 1108107 Summary: perl-Text-CSV_XS-1.09 is available Product: Fedora Version: rawhide Component: perl-Text-CSV_XS Keywords: FutureFeature, Triaged Assignee: psab...@redhat.com Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: mmasl...@redhat.com, perl-de...@lists.fedoraproject.org, psab...@redhat.com Latest upstream release: 1.09 Current version/release in Fedora Rawhide: 1.08-2.fc21 URL: http://search.cpan.org/dist/Text-CSV_XS/ Please consult the package updates policy before you issue an update to a stable branch: https://fedoraproject.org/wiki/Updates_Policy More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=CcOj2UWxoba=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 1032581] perlbrew-0.69 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1032581 Upstream Release Monitoring upstream-release-monitor...@fedoraproject.org changed: What|Removed |Added Summary|perlbrew-0.68 is available |perlbrew-0.69 is available --- Comment #2 from Upstream Release Monitoring upstream-release-monitor...@fedoraproject.org --- Latest upstream release: 0.69 Current version/release in Fedora Rawhide: 0.66-2.fc21 URL: http://search.cpan.org/dist/App-perlbrew/ Please consult the package updates policy before you issue an update to a stable branch: https://fedoraproject.org/wiki/Updates_Policy More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=vW0nQPK0jva=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Schedule for Wednesday's FESCo Meeting (2014-06-11)
Following is the list of topics that will be discussed in the FESCo meeting Wednesday at 17:00UTC in #fedora-meeting on irc.freenode.net. To convert UTC to your local time, take a look at http://fedoraproject.org/wiki/UTCHowto or run: date -d '2014-06-11 17:00 UTC' Links to all tickets below can be found at: https://fedorahosted.org/fesco/report/9 = Followups = #topic #1221 Product working group activity reports .fesco 1221 https://fedorahosted.org/fesco/ticket/1221 = New business = #topic #1311 Disable syscall auditing by default .fesco 1311 https://fedorahosted.org/fesco/ticket/1311 #topic #1310 Reconsidering rpcbind's exception allowing it to start by default .fesco 1310 https://fedorahosted.org/fesco/ticket/1310 = Open Floor = For more complete details, please visit each individual ticket. The report of the agenda items can be found at https://fedorahosted.org/fesco/report/9 If you would like to add something to this agenda, you can reply to this e-mail, file a new ticket at https://fedorahosted.org/fesco, e-mail me directly, or bring it up at the end of the meeting, during the open floor topic. Note that added topics may be deferred until the following meeting. -Toshio pgpap7_js4ZBd.pgp Description: PGP signature -- 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: F22 System Wide Change: Replace Yum With DNF
On Wed, Jun 11, 2014 at 2:44 PM, Jaroslav Reznik jrez...@redhat.com wrote: = Proposed System Wide Change: Replace Yum With DNF = https://fedoraproject.org/wiki/Changes/ReplaceYumWithDNF Note: This is Fedora 22 proposal! Change owner(s): Aleš Kozumplík kozump...@gmail.com Make DNF/Yum4 the new default packaging tool in F22. == Detailed Description == DNF was forked from Yum in January 2012 and available for experimenting in Fedora since release 18 [1]. The project is now fully capable of replacing Yum in new Fedora installations. We want DNF to become the new default packaging tool in Fedora 22. This entails: * letting system administrators (including users who routinely manage their packages using the legacy Yum) perform all common packaging operations using DNF, with no or minimal and documented [2] change to the command syntax, apart from replacing the command name. (done) * providing implementation of Anaconda backend so system can be bootstrapped completely without using legacy Yum. (done) * providing alternative to all Yum plugins from yum-utils (ongoing) * providing alternative to all release engineering tools (repoquery, bodhi etc.) from yum-utils (ongoing) * being ready/having the capacity to help out users with migration of their custom legacy plugins and extensions to DNF. The solid API documentation [3] we provide is of great advantage here. (ongoing) In practice, the change implies: * Anaconda installs the system using the DNF backend (with no special switches) * package 'dnf' is installed by default (referenced by the base comps groups) * package 'dnf-yum-compat-command' is installed by default. It obsoletes Yum and provides its own code/usr/bin/yum/code, a short script that redirects to code/usr/bin/dnf/code with an appropriate warning message that DNF is the preferred package manager now. Notice that upgrading F21 to F22 will not cause the compat package to be installed so will not disturb any upgrading users. That makes no sense. First of all if it obsoletes yum it will get pulled in during upgrades and imo it *should*. We don't really want to end up in a situation where half the users are using the default packing tool while the other half uses the old one. We should really just do the right think and properly obsolete yum without a compact package ... keeping yum serves no purpose. As for Matthew's mail ... I don't think people will forgot about Seth because yum is gone if that's the case it would be really sad also why maybe his biggest yum was not his only contribution. -- 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: Make fails with fedora build options set
On Tue, Jun 10, 2014 at 9:23 PM, Adam Williamson awill...@redhat.com wrote:
On Fri, 2014-05-02 at 07:07 +0200, Stanislav Ochotnicky wrote:
On Thu 01 May 2014 01:34:43 PM CEST Jon Kent wrote:
Hi,
I'm trying to get a GnuBatch package into Fedora, which is currently
being reviewed. One of the points raised in the review was that I was
running make without any Fedora options. I've added these as requested
so the make line now looks like:
make %{?_smp_mflags} CFLAGS=%{optflags} BINDIR=%{_bindir}
This expands out to :
make -j4 CFLAGS=-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions
-fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches
-m64 -mtune=generic BINDIR=/usr/bin
However with these options the build is now failing where is was working
fine before using just make. The errors are related to being unable to
find the header files (i.e. config.h). I've tried added -I option
pointing to the header directory but this did not help.
What I don't understand is why this worked before, where as with these
make options set the build now fails. Any pointers much appreciated as
I'm just going in circles here trying to resolve this problem.
The below is an part of the output I get when this fails:
make[4]: Entering directory
`/home/jon/rpmbuild/BUILD/gnubatch-1.10/util'
gcc -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions
-fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches
-m64 -mtune=generic -c -o helpparse.o helpparse.c
helpparse.c:18:20: fatal error: config.h: No such file or directory
#include config.h
Another (relatively common) problem is the parallelization (-j4)
tripping the makefile up. I.e. dependencies for some targets are
incomplete and config.h is not yet generated when they execute.
Any time this turns out to be the problem, add a comment explaining that
parallel build is disabled because it causes problems.
While this is an option its a kludge ... how about fix it and send
the patch upstream ?
--
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: F22 System Wide Change: Replace Yum With DNF
Am 11.06.2014 16:08, schrieb drago01: We should really just do the right think and properly obsolete yum without a compact package ... keeping yum serves no purpose. As for Matthew's mail ... I don't think people will forgot about Seth because yum is gone if that's the case it would be really sad also why maybe his biggest yum was not his only contribution if it obsoletes and replaces yum it has to provide /usr/bin/yum because one of the reasons Linux is not that widely used is because you have all the time replace and rewrite things while a smart upstream could avoid that by just place symlinks or not break compatibility for the sake of changes and yes i think it would be a great idea install DNF only on new F22 setups while obsolete and replace yum finally one release later to get more widely testing and at the same time avopid to break 5 and more years old server setups with scripting around yum because some of the early bugs maybe be reported by the users of new install and fixed until F23 signature.asc Description: OpenPGP digital signature -- 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: F22 System Wide Change: Replace Yum With DNF
On Wed, Jun 11, 2014 at 4:13 PM, Reindl Harald h.rei...@thelounge.net wrote: Am 11.06.2014 16:08, schrieb drago01: We should really just do the right think and properly obsolete yum without a compact package ... keeping yum serves no purpose. As for Matthew's mail ... I don't think people will forgot about Seth because yum is gone if that's the case it would be really sad also why maybe his biggest yum was not his only contribution if it obsoletes and replaces yum it has to provide /usr/bin/yum That's what I have said (just with the if). [...] and yes i think it would be a great idea install DNF only on new F22 setups while obsolete and replace yum finally one release later to get more widely testing and at the same time avopid to break 5 and more years old server setups with scripting around yum because some of the early bugs maybe be reported by the users of new install and fixed until F23 No I disagree here. We already have (and are still in) a optional to test for user and it gets active testing. Its time to flip the switch. -- 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: F22 System Wide Change: Replace Yum With DNF
Am 11.06.2014 16:20, schrieb drago01: On Wed, Jun 11, 2014 at 4:13 PM, Reindl Harald h.rei...@thelounge.net wrote: Am 11.06.2014 16:08, schrieb drago01: We should really just do the right think and properly obsolete yum without a compact package ... keeping yum serves no purpose. As for Matthew's mail ... I don't think people will forgot about Seth because yum is gone if that's the case it would be really sad also why maybe his biggest yum was not his only contribution if it obsoletes and replaces yum it has to provide /usr/bin/yum That's what I have said (just with the if). [...] and yes i think it would be a great idea install DNF only on new F22 setups while obsolete and replace yum finally one release later to get more widely testing and at the same time avopid to break 5 and more years old server setups with scripting around yum because some of the early bugs maybe be reported by the users of new install and fixed until F23 No I disagree here. We already have (and are still in) a optional to test for user and it gets active testing. Its time to flip the switch well, that's something different than have on a new setup DNF instead YUM and if things are working properly you don't notice, make a reality check: the way a optin-user tests and classifies things are completly different as a random user not knowing about the replacement if sensible core components are replaced there should be a way back in case of troubles and not a dry there where testers live with it those testers until now maybe not represent the relevant usecases if i replace software i do it always in steps and that is why i did not breaks cumstomers setups the last 11 years: * internal tests * asking some representative users for testing * update a picked set of users without saying anything * if they report troubles try to fix them within 2 up to 5 hours * if that's not possible revert the change for them * try to fix the problem without angry users * roll it out again for the picked set * and then roll it out for everybody * and even in that last step there must exist a way back the golden rule for accepted big changes is *never* break users setup and never make a abusive change with no way back and leave only telling him he has to chew and adopt signature.asc Description: OpenPGP digital signature -- 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: F22 System Wide Change: Replace Yum With DNF
On Wed, Jun 11, 2014 at 4:30 PM, Reindl Harald h.rei...@thelounge.net wrote: Am 11.06.2014 16:20, schrieb drago01: On Wed, Jun 11, 2014 at 4:13 PM, Reindl Harald h.rei...@thelounge.net wrote: Am 11.06.2014 16:08, schrieb drago01: We should really just do the right think and properly obsolete yum without a compact package ... keeping yum serves no purpose. As for Matthew's mail ... I don't think people will forgot about Seth because yum is gone if that's the case it would be really sad also why maybe his biggest yum was not his only contribution if it obsoletes and replaces yum it has to provide /usr/bin/yum That's what I have said (just with the if). [...] and yes i think it would be a great idea install DNF only on new F22 setups while obsolete and replace yum finally one release later to get more widely testing and at the same time avopid to break 5 and more years old server setups with scripting around yum because some of the early bugs maybe be reported by the users of new install and fixed until F23 No I disagree here. We already have (and are still in) a optional to test for user and it gets active testing. Its time to flip the switch well, that's something different than have on a new setup DNF instead YUM and if things are working properly you don't notice, make a reality check: the way a optin-user tests and classifies things are completly different as a random user not knowing about the replacement if sensible core components are replaced there should be a way back in case of troubles and not a dry there where testers live with it those testers until now maybe not represent the relevant usecases if i replace software i do it always in steps and that is why i did not breaks cumstomers setups the last 11 years: * internal tests * asking some representative users for testing * update a picked set of users without saying anything * if they report troubles try to fix them within 2 up to 5 hours * if that's not possible revert the change for them * try to fix the problem without angry users * roll it out again for the picked set * and then roll it out for everybody * and even in that last step there must exist a way back the golden rule for accepted big changes is *never* break users setup and never make a abusive change with no way back and leave only telling him he has to chew and adopt Sure but that should also applies to upgrades (i.e do not just upgrade on productive systems without prior testing on a replicated test environment; which you probably do anyway). I am not really opposed to having a way back if it is opt in and not simply split the userbase based on how the system got installed (this is a mess to support comparing to having a handful of users that opted to go back). Support aside at least the workstation prd states that upgrades should not have a worse expirence then new installs having a slower depsolver / package installer would fall into that. -- 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: Schedule for Wednesday's FESCo Meeting (2014-06-11)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 06/11/2014 09:36 AM, Toshio Kuratomi wrote: Following is the list of topics that will be discussed in the FESCo meeting Wednesday at 17:00UTC in #fedora-meeting on irc.freenode.net. To convert UTC to your local time, take a look at http://fedoraproject.org/wiki/UTCHowto or run: date -d '2014-06-11 17:00 UTC' Links to all tickets below can be found at: https://fedorahosted.org/fesco/report/9 = Followups = #topic #1221 Product working group activity reports .fesco 1221 https://fedorahosted.org/fesco/ticket/1221 = New business = #topic #1311 Disable syscall auditing by default .fesco 1311 https://fedorahosted.org/fesco/ticket/1311 #topic #1310 Reconsidering rpcbind's exception allowing it to start by default .fesco 1310 https://fedorahosted.org/fesco/ticket/1310 = Open Floor = For more complete details, please visit each individual ticket. The report of the agenda items can be found at https://fedorahosted.org/fesco/report/9 If you would like to add something to this agenda, you can reply to this e-mail, file a new ticket at https://fedorahosted.org/fesco, e-mail me directly, or bring it up at the end of the meeting, during the open floor topic. Note that added topics may be deferred until the following meeting. I forgot to open a ticket over the last week, but the Server WG has identified that completion of its core task (the Server Role API) is likely to need a little extra time. This is a blocker to release, so we figured it would be best to ask FESCo to modify the schedule in advance, rather than forcing a slip at the end. I'll bring this up in Open Floor, unless you want to add it to the formal agenda. -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlOYacIACgkQeiVVYja6o6O8KACeJn97OolXkvHy8rotx5hWJRVs /joAn0f24FKaJgcqUy2FcMubHENXrxNu =nyC2 -END PGP SIGNATURE- -- 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: F22 System Wide Change: Replace Yum With DNF
On Wed, Jun 11, 2014 at 04:08:09PM +0200, drago01 wrote: We should really just do the right think and properly obsolete yum without a compact package ... keeping yum serves no purpose. As for Matthew's mail ... I don't think people will forgot about Seth because yum is gone if that's the case it would be really sad also why maybe his biggest yum was not his only contribution. Oh, of course not. I just think it would be a nice (and respectful) thing to do. (I do notice that the feature page mentions yum 4, which I assume is a consideration of this approach.) -- Matthew Miller mat...@fedoraproject.org Fedora Project Leader -- 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: Schedule for Wednesday's FESCo Meeting (2014-06-11)
On Wed, Jun 11, 2014 at 10:37:54AM -0400, Stephen Gallagher wrote: I forgot to open a ticket over the last week, but the Server WG has identified that completion of its core task (the Server Role API) is likely to need a little extra time. This is a blocker to release, so we figured it would be best to ask FESCo to modify the schedule in advance, rather than forcing a slip at the end. Since I am not going to be there: I am -1 to squeezing in more time early on without pushing the rest back, because I think that's just lying to ourselves. I'm... +0.5 in slipping the whole schedule, I guess -- I wish we had this when making the initial plan, but I also know how reality works. Might as well round that to +1. :) -- Matthew Miller mat...@fedoraproject.org Fedora Project Leader -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Slipping F21 (was: Schedule for Wednesday's FESCo Meeting (2014-06-11))
On 06/11/2014 04:37 PM, Stephen Gallagher wrote: I forgot to open a ticket over the last week, but the Server WG has identified that completion of its core task (the Server Role API) is likely to need a little extra time. This is a blocker to release, so we figured it would be best to ask FESCo to modify the schedule in advance, rather than forcing a slip at the end. I'll bring this up in Open Floor, unless you want to add it to the formal agenda. How much time do you think you'd need to complete the Server Role API? With my Workstation WG hat on, I'd very much like to avoid pushing back the schedule. We already skipped one whole release; if we slip F21 it's going to negatively impact how users perceive the Workstation, and make it harder for Workstation developers to work on the code upstream. At the very least, please don't do a quick decision on today's IRC meeting and allow some time to discuss this with other WGs. An alternative to slipping would also be to skip Server this release cycle if it's not ready. Could try again in 6 months. -- Kalev -- 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: F22 System Wide Change: Replace Yum With DNF
On 11. 6. 2014 at 09:02:29, Rahul Sundaram wrote: Hi On Wed, Jun 11, 2014 at 8:52 AM, Matthew Miller wrote: This is kind of sentimental, and I think possibly Seth would not have liked to have a big deal made of it, but... I guess I'm going to anyway. I would like to keep the yum name in remembrance of his contributions. This also seems like the easiest path for all of the documentation, scripts, and user habits out there. I don't mind if the backend package is called dnf, but why not keep /usr/bin/yum as the primary command and just do the right thing, only warning on incompatible usage rather than nagging every time it is used? I strongly agree with this for practical reasons. There is no good rationale for moving away from yum as the name of the command except some of the command line changes which happened with yum anyway (download only was added and later removed for example) and one can warn specifically for those. The API changes are not something users care about. Also, dnf needs to drop all the legacy options before the transition (ie) pick erase or remove (preferably the latter) etc rather than retain all the compatibility options. The transition period is one reason why we want to keep the name dnf. We'd basically like to keep current yum around for users that have various scripts and stuff depending on it so they have some time to migrate to dnf. Also presenting dnf as a separate project forked from yum gives us better flexibility - for instance it's easier to drop obsoleted stuff because users don't have that high compatibility expectations. Thanks Jan -- 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: F22 System Wide Change: Replace Yum With DNF
On 11. 6. 2014 at 08:52:34, Matthew Miller wrote: On Wed, Jun 11, 2014 at 02:44:10PM +0200, Jaroslav Reznik wrote: * package 'dnf-yum-compat-command' is installed by default. It obsoletes Yum and provides its own code/usr/bin/yum/code, a short script that redirects to code/usr/bin/dnf/code with an appropriate warning message that DNF is the preferred package manager now. Notice that upgrading F21 to F22 will not cause the compat package to be installed so will not disturb any upgrading users. This is kind of sentimental, and I think possibly Seth would not have liked to have a big deal made of it, but... I guess I'm going to anyway. I would like to keep the yum name in remembrance of his contributions. This also seems like the easiest path for all of the documentation, scripts, and user habits out there. I don't mind if the backend package is called dnf, but why not keep /usr/bin/yum as the primary command and just do the right thing, only warning on incompatible usage rather than nagging every time it is used? Actually the plan is to keep /usr/bin/yum as the primary command during the transition but it will do something similar to what the /sbin/service command does now. It will redirect to dnf and give user a message that it is redirecting to dnf. As for scripts, that's actually another reason why to keep yum around. Some scripts might not be able to handle some of the minor differences and some python scripts might still want to use the yum python API. That's why it makes sense to keep yum around for a few releases as a fallback. Thanks Jan -- 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: F22 System Wide Change: Replace Yum With DNF
Hi On Wed, Jun 11, 2014 at 11:20 AM, Jan Zelený wrote: The transition period is one reason why we want to keep the name dnf. We'd basically like to keep current yum around for users that have various scripts and stuff depending on it so they have some time to migrate to dnf. I would suggest doing it the other way around. Rename old yum to yum-legacy. Rename dnf to yum and at the end of the transition period drop yum-legacy and retain yum as the command line name. For any deprecation options, warn on them and suggest the supported alternative. With your current plan, after the transition period, everyone has to retrain themselves to type dnf instead of yum which I don't think is necessary. Rahul -- 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: [fedora-arm] ExcludeArch tracker doesn't appear to be effective
On Wed, Jun 11, 2014 at 09:14:24AM +0100, Richard W.M. Jones wrote: This ought to improve greatly with 64 bit ARM, where Red Hat are pushing for everything to support UEFI booting and ACPI for hardware description. A single upstream open source kernel should [eventually] be able to boot on every aarch64 machine, even ones that have not been seen before. UEFI should be an improvement in this respect, but there's really no fundamental benefit to using ACPI rather than DTB for hardware description. -- Matthew Garrett | mj...@srcf.ucam.org -- 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: Slipping F21 (was: Schedule for Wednesday's FESCo Meeting (2014-06-11))
On 11 June 2014 15:56, Kalev Lember kalevlem...@gmail.com wrote: With my Workstation WG hat on, I'd very much like to avoid pushing back the schedule. We already skipped one whole release; if we slip F21 it's going to negatively impact how users perceive the Workstation, and make it harder for Workstation developers to work on the code upstream. 100% agree -- without my fedora-21-gnome-3-12 COPR I'd have to be using Arch to test system-wide GNOME things. Richard. -- 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: Schedule for Wednesday's FESCo Meeting (2014-06-11)
- Original Message - -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 06/11/2014 09:36 AM, Toshio Kuratomi wrote: Following is the list of topics that will be discussed in the FESCo meeting Wednesday at 17:00UTC in #fedora-meeting on irc.freenode.net. To convert UTC to your local time, take a look at http://fedoraproject.org/wiki/UTCHowto or run: date -d '2014-06-11 17:00 UTC' Links to all tickets below can be found at: https://fedorahosted.org/fesco/report/9 = Followups = #topic #1221 Product working group activity reports .fesco 1221 https://fedorahosted.org/fesco/ticket/1221 = New business = #topic #1311 Disable syscall auditing by default .fesco 1311 https://fedorahosted.org/fesco/ticket/1311 #topic #1310 Reconsidering rpcbind's exception allowing it to start by default .fesco 1310 https://fedorahosted.org/fesco/ticket/1310 = Open Floor = For more complete details, please visit each individual ticket. The report of the agenda items can be found at https://fedorahosted.org/fesco/report/9 If you would like to add something to this agenda, you can reply to this e-mail, file a new ticket at https://fedorahosted.org/fesco, e-mail me directly, or bring it up at the end of the meeting, during the open floor topic. Note that added topics may be deferred until the following meeting. I forgot to open a ticket over the last week, but the Server WG has identified that completion of its core task (the Server Role API) is likely to need a little extra time. This is a blocker to release, so we figured it would be best to ask FESCo to modify the schedule in advance, rather than forcing a slip at the end. Or just update the change ticket for roles framework to have it in one place. Btw. how much server roles are delayed? I think we could absorb reasonable delay within current schedule but it really depends on WGs request. Jaroslav I'll bring this up in Open Floor, unless you want to add it to the formal agenda. -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlOYacIACgkQeiVVYja6o6O8KACeJn97OolXkvHy8rotx5hWJRVs /joAn0f24FKaJgcqUy2FcMubHENXrxNu =nyC2 -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- 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: Schedule for Wednesday's FESCo Meeting (2014-06-11)
On Wed, Jun 11, 2014 at 9:36 AM, Toshio Kuratomi a.bad...@gmail.com wrote: If you would like to add something to this agenda, you can reply to this e-mail, file a new ticket at https://fedorahosted.org/fesco, e-mail me directly, or bring it up at the end of the meeting, during the open floor topic. Note that added topics may be deferred until the following meeting. Should probably discuss Bill's departure and how you want to handle the open seat. josh -- 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: F22 System Wide Change: Replace Yum With DNF
On Wed, Jun 11, 2014 at 05:21:30PM +0200, Jan Zelený wrote: On 11. 6. 2014 at 08:52:34, Matthew Miller wrote: On Wed, Jun 11, 2014 at 02:44:10PM +0200, Jaroslav Reznik wrote: * package 'dnf-yum-compat-command' is installed by default. It obsoletes Yum and provides its own code/usr/bin/yum/code, a short script that redirects to code/usr/bin/dnf/code with an appropriate warning message that DNF is the preferred package manager now. Notice that upgrading F21 to F22 will not cause the compat package to be installed so will not disturb any upgrading users. This is kind of sentimental, and I think possibly Seth would not have liked to have a big deal made of it, but... I guess I'm going to anyway. I would like to keep the yum name in remembrance of his contributions. This also seems like the easiest path for all of the documentation, scripts, and user habits out there. I don't mind if the backend package is called dnf, but why not keep /usr/bin/yum as the primary command and just do the right thing, only warning on incompatible usage rather than nagging every time it is used? Actually the plan is to keep /usr/bin/yum as the primary command during the transition but it will do something similar to what the /sbin/service command does now. It will redirect to dnf and give user a message that it is redirecting to dnf. As for scripts, that's actually another reason why to keep yum around. Some scripts might not be able to handle some of the minor differences and some python scripts might still want to use the yum python API. That's why it makes sense to keep yum around for a few releases as a fallback. Have puppet, chef, ansible, salt, etc. been taught how to use dnf to install packages? I think it would be a shame to force all this software to do s/yum/dnf/ or to have to conditionally code for these differences based on OS release or the presense of yum vs. dnf. Why not just keep the command name the same with no nag message? -- 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: Slipping F21 (was: Schedule for Wednesday's FESCo Meeting (2014-06-11))
Kalev Lember píše v St 11. 06. 2014 v 16:56 +0200: On 06/11/2014 04:37 PM, Stephen Gallagher wrote: I forgot to open a ticket over the last week, but the Server WG has identified that completion of its core task (the Server Role API) is likely to need a little extra time. This is a blocker to release, so we figured it would be best to ask FESCo to modify the schedule in advance, rather than forcing a slip at the end. I'll bring this up in Open Floor, unless you want to add it to the formal agenda. How much time do you think you'd need to complete the Server Role API? If it's more than a month, then I don't agree with the slip of the whole release. With my Workstation WG hat on, I'd very much like to avoid pushing back the schedule. We already skipped one whole release; if we slip F21 it's going to negatively impact how users perceive the Workstation, and make it harder for Workstation developers to work on the code upstream. At the very least, please don't do a quick decision on today's IRC meeting and allow some time to discuss this with other WGs. +1, this is an important decision that can't be done after a short discussion over a ticket that came last minute. An alternative to slipping would also be to skip Server this release cycle if it's not ready. Could try again in 6 months. +1, we've already skipped one release and we just can't delay significantly more. Fedora is known as a fast-moving distribution. A large portion of our user base is using Fedora just for that reason. Do we really want to make even more of them switch to Arch? Release early, release often. We can't wait forever. If one of the products can't make it this release they can jump on train next release. There won't be any regression for server users compared to F20. Jiri -- 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: F22 System Wide Change: Replace Yum With DNF
Am 11.06.2014 17:37, schrieb Chuck Anderson: Have puppet, chef, ansible, salt, etc. been taught how to use dnf to install packages? I think it would be a shame to force all this software to do s/yum/dnf/ or to have to conditionally code for these differences based on OS release or the presense of yum vs. dnf. Why not just keep the command name the same with no nag message? because it is not state of the art to change things in a way that the change is not heavily noticed to point out look we have done something and now it's your turn hopefully coreutils will not get a replacement in the next cycle with the commands move, copy, removedir, Listddir and obsolete mv, cp, rmdir, ls signature.asc Description: OpenPGP digital signature -- 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: Slipping F21
Am 11.06.2014 17:41, schrieb Jiri Eischmann: +1, we've already skipped one release and we just can't delay significantly more. Fedora is known as a fast-moving distribution. A large portion of our user base is using Fedora just for that reason. Do we really want to make even more of them switch to Arch? um F20 has Kernel 3.14, recent mesa, KDE 4.13 soon, recent LibreOffice and so on - what are you missing that justifies move move, go on move! signature.asc Description: OpenPGP digital signature -- 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: Slipping F21 (was: Schedule for Wednesday's FESCo Meeting (2014-06-11))
- Original Message - From: Richard Hughes hughsi...@gmail.com To: Discussions about development for the Fedora desktop desk...@lists.fedoraproject.org Cc: Development discussions related to Fedora devel@lists.fedoraproject.org Sent: Wednesday, June 11, 2014 6:28:06 PM Subject: Re: Slipping F21 (was: Schedule for Wednesday's FESCo Meeting (2014-06-11)) On 11 June 2014 15:56, Kalev Lember kalevlem...@gmail.com wrote: With my Workstation WG hat on, I'd very much like to avoid pushing back the schedule. We already skipped one whole release; if we slip F21 it's going to negatively impact how users perceive the Workstation, and make it harder for Workstation developers to work on the code upstream. 100% agree -- without my fedora-21-gnome-3-12 COPR I'd have to be using Arch to test system-wide GNOME things. Let me join - Please don't slip Fedora 21 release even more. Fedora 20 is already showing its age and looking for another OS to test future work is not fun at all and it happens already. Alexander Kurtakov Red Hat Eclipse team Richard. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- 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: ssh problem with pkgs.fedoraproject.org
On Wed, 11 Jun 2014 14:02:08 +0100 Jonathan Underwood jonathan.underw...@gmail.com wrote: I too am now seeing exactly this problem I'll email Kevin my IP address too... unless there's a more generic infra email address I should send to? Usually the best thing would be to open a infrastructure ticket. I've hopefully fixed your IP too now tho. ;) kevin signature.asc Description: PGP signature -- 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: Slipping F21
On Wed, Jun 11, 2014 at 5:44 PM, Reindl Harald h.rei...@thelounge.net wrote: Am 11.06.2014 17:41, schrieb Jiri Eischmann: +1, we've already skipped one release and we just can't delay significantly more. Fedora is known as a fast-moving distribution. A large portion of our user base is using Fedora just for that reason. Do we really want to make even more of them switch to Arch? um F20 has Kernel 3.14, recent mesa, KDE 4.13 soon, recent LibreOffice and so on - what are you missing that justifies move move, go on move! GNOME? -- 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: ssh problem with pkgs.fedoraproject.org
On 11 June 2014 16:50, Kevin Fenzi ke...@scrye.com wrote: On Wed, 11 Jun 2014 14:02:08 +0100 Jonathan Underwood jonathan.underw...@gmail.com wrote: I too am now seeing exactly this problem I'll email Kevin my IP address too... unless there's a more generic infra email address I should send to? Usually the best thing would be to open a infrastructure ticket. OK, noted. I've hopefully fixed your IP too now tho. ;) OK, thanks, will check. J. -- 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: Slipping F21
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 (Sorry for double-reply; forgot to copy both lists) On 06/11/2014 10:56 AM, Kalev Lember wrote: On 06/11/2014 04:37 PM, Stephen Gallagher wrote: I forgot to open a ticket over the last week, but the Server WG has identified that completion of its core task (the Server Role API) is likely to need a little extra time. This is a blocker to release, so we figured it would be best to ask FESCo to modify the schedule in advance, rather than forcing a slip at the end. I'll bring this up in Open Floor, unless you want to add it to the formal agenda. How much time do you think you'd need to complete the Server Role API? We were planning to ask for two additional weeks on the schedule. We are not really expecting to get all of it. With my Workstation WG hat on, I'd very much like to avoid pushing back the schedule. We already skipped one whole release; if we slip F21 it's going to negatively impact how users perceive the Workstation, and make it harder for Workstation developers to work on the code upstream. I agree, we don't want to slip much at all. I probably should have been clearer about the amount of slip we were going to ask for in the mail. At the very least, please don't do a quick decision on today's IRC meeting and allow some time to discuss this with other WGs. An alternative to slipping would also be to skip Server this release cycle if it's not ready. Could try again in 6 months. This would be a significant overreaction, I think. -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlOYezsACgkQeiVVYja6o6Ni3QCcDL0zFaFOWg4oWkO8LW3zkoKz vt0AoJnHTi1aGVesP2XAg5F5kAs9pJ6c =7HDl -END PGP SIGNATURE- -- 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: Slipping F21
- Original Message - From: Reindl Harald h.rei...@thelounge.net To: devel@lists.fedoraproject.org Sent: Wednesday, June 11, 2014 6:44:09 PM Subject: Re: Slipping F21 Am 11.06.2014 17:41, schrieb Jiri Eischmann: +1, we've already skipped one release and we just can't delay significantly more. Fedora is known as a fast-moving distribution. A large portion of our user base is using Fedora just for that reason. Do we really want to make even more of them switch to Arch? um F20 has Kernel 3.14, recent mesa, KDE 4.13 soon, recent LibreOffice and so on - what are you missing that justifies move move, go on move! Let me reply for myself - Maven 3.2, Java 8 by default, Eclipse 4.4, GTK 3.12, Webkitgtk 2.4, XMvn and other packager tools changes. Let's not forget that many people use Fedora as their development machine and having your users reporting bugs when working with libraries/tools newer than available in latest fedora kills the reason into using fedora. Alexander Kurtakov Red Hat Eclipse team -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- 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: Slipping F21
On Wed, Jun 11, 2014 at 5:51 PM, drago01 drag...@gmail.com wrote: On Wed, Jun 11, 2014 at 5:44 PM, Reindl Harald h.rei...@thelounge.net wrote: Am 11.06.2014 17:41, schrieb Jiri Eischmann: +1, we've already skipped one release and we just can't delay significantly more. Fedora is known as a fast-moving distribution. A large portion of our user base is using Fedora just for that reason. Do we really want to make even more of them switch to Arch? um F20 has Kernel 3.14, recent mesa, KDE 4.13 soon, recent LibreOffice and so on - what are you missing that justifies move move, go on move! GNOME? Oh and xserver really .. I am the one that gets complaints from users that I can't fix because of our ancient x11 stack. -- 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: Slipping F21
Reindl Harald píše v St 11. 06. 2014 v 17:44 +0200: Am 11.06.2014 17:41, schrieb Jiri Eischmann: +1, we've already skipped one release and we just can't delay significantly more. Fedora is known as a fast-moving distribution. A large portion of our user base is using Fedora just for that reason. Do we really want to make even more of them switch to Arch? um F20 has Kernel 3.14, recent mesa, KDE 4.13 soon, recent LibreOffice and so on - what are you missing that justifies move move, go on move! Well... where do I start? For example the whole default desktop platform? Yes, we have GNOME 3.12 Copr, but it brings practical problems. The whole graphics stack also cannot be completely rebased (it would require new LLVM which would be too significant change within one release) to benefit from all the great work Valve's initiative brought in the last months. So Fedora is not very appealing gaming platform these days. I guess everyone can pick something that they care about and that has become old since the freeze of F20. Jiri -- 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: Slipping F21 (was: Schedule for Wednesday's FESCo Meeting (2014-06-11))
My personal opinion is that we ought to try not disrupting the release schedule. If some features miss the release train, it could wait 6 monthq (and, I disagree with dropping the whole server products). Fedora.Next is a big change in our model, our priority is to release F21 and get some feedbacks so we can adjust the plan. Delaying F21 anymore is quite risky for us, I'd rather have a less ambitious release than getting stuck. H. -- 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: [fedora-arm] ExcludeArch tracker doesn't appear to be effective
On Wed, Jun 11, 2014 at 10:14 AM, Richard W.M. Jones rjo...@redhat.com wrote: On Wed, Jun 11, 2014 at 12:07:23AM +0200, drago01 wrote: On Tue, Jun 10, 2014 at 11:52 PM, Peter Robinson pbrobin...@gmail.com wrote: [...] So moving on from that why don't you feel comfortable pointing to the ARM port? The question wasn't really directed at me but adding my 2 cents ... basically on x86(_64) hardware I can point people at fedora and most of the time it will work. As for ARM if you get a random arm hardware chances are that it is simply not supported or needs some manual hacks to get used. That's not really a fedora specific problem but it makes ARM more of a gimmick to me ... until hardware vendors catch up. As you say, mostly this is the nature of the platform. 32 bit ARM hardware is not self-describing, and not at all uniform (unlike PCs). There is no BIOS. There's no standard text display or serial port. Yeah I know but it still makes it inferior to x86_64 ... debian seems to be in a better shape simply because it supported ARM for a long time (i.e there builds for a larger set of boards). I have never bough an ARM board (just got them through various ways) the two that I still have do not work on fedora. One can be made to work with some effort while the I don't know what the state of the other one is. This ought to improve greatly with 64 bit ARM, where Red Hat are pushing for everything to support UEFI booting and ACPI for hardware description. A single upstream open source kernel should [eventually] be able to boot on every aarch64 machine, even ones that have not been seen before. Yeah looking forward to that. The current system does not scale for a general purpose distribution. -- 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: ssh problem with pkgs.fedoraproject.org
On Wed, Jun 11, 2014 at 9:50 AM, Kevin Fenzi ke...@scrye.com wrote: Usually the best thing would be to open a infrastructure ticket. I've hopefully fixed your IP too now tho. ;) This kind of problem is just going to keep happening to those of us with dynamic IP addresses from large ISPs. Plus, since there are multiple possible causes of the error message that gets generated as a result, it takes the poor sap who experiences the problem some time and difficulty to figure out that his IP address has been blocked at the server side. (I speak from experience.) I hate to say it, but maybe denyhosts shouldn't be used in this case. -- Jerry James http://www.jamezone.org/ -- 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: ssh problem with pkgs.fedoraproject.org
On 11 June 2014 10:04, Jerry James loganje...@gmail.com wrote: On Wed, Jun 11, 2014 at 9:50 AM, Kevin Fenzi ke...@scrye.com wrote: Usually the best thing would be to open a infrastructure ticket. I've hopefully fixed your IP too now tho. ;) This kind of problem is just going to keep happening to those of us with dynamic IP addresses from large ISPs. Plus, since there are multiple possible causes of the error message that gets generated as a result, it takes the poor sap who experiences the problem some time and difficulty to figure out that his IP address has been blocked at the server side. (I speak from experience.) I hate to say it, but maybe denyhosts shouldn't be used in this case. It happens maybe once a month which while annoying is better than having the server not responding to ssh because 4000 bots are trying to login with root, password and bin, password, etc etc. -- Stephen J Smoogen. -- 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: ssh problem with pkgs.fedoraproject.org
Once upon a time, Jerry James loganje...@gmail.com said: On Wed, Jun 11, 2014 at 9:50 AM, Kevin Fenzi ke...@scrye.com wrote: Usually the best thing would be to open a infrastructure ticket. I've hopefully fixed your IP too now tho. ;) This kind of problem is just going to keep happening to those of us with dynamic IP addresses from large ISPs. Plus, since there are multiple possible causes of the error message that gets generated as a result, it takes the poor sap who experiences the problem some time and difficulty to figure out that his IP address has been blocked at the server side. (I speak from experience.) I hate to say it, but maybe denyhosts shouldn't be used in this case. Yeah, I've found fail2ban (where IP blocks are expired in a reasonable time) to be a much better option than denyhosts. It is also nicer to the server because you can block connections with iptables, rather than forking sshd processes only to close the connection. Also, if you want, you can configure fail2ban with escalating length blocks (so first offense is 5 minutes, then 3 strikes gets you an hour, etc.). -- Chris Adams li...@cmadams.net -- 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: F22 System Wide Change: Replace Yum With DNF
Le mercredi 11 juin 2014 à 11:37 -0400, Chuck Anderson a écrit : On Wed, Jun 11, 2014 at 05:21:30PM +0200, Jan Zelený wrote: On 11. 6. 2014 at 08:52:34, Matthew Miller wrote: On Wed, Jun 11, 2014 at 02:44:10PM +0200, Jaroslav Reznik wrote: * package 'dnf-yum-compat-command' is installed by default. It obsoletes Yum and provides its own code/usr/bin/yum/code, a short script that redirects to code/usr/bin/dnf/code with an appropriate warning message that DNF is the preferred package manager now. Notice that upgrading F21 to F22 will not cause the compat package to be installed so will not disturb any upgrading users. This is kind of sentimental, and I think possibly Seth would not have liked to have a big deal made of it, but... I guess I'm going to anyway. I would like to keep the yum name in remembrance of his contributions. This also seems like the easiest path for all of the documentation, scripts, and user habits out there. I don't mind if the backend package is called dnf, but why not keep /usr/bin/yum as the primary command and just do the right thing, only warning on incompatible usage rather than nagging every time it is used? Actually the plan is to keep /usr/bin/yum as the primary command during the transition but it will do something similar to what the /sbin/service command does now. It will redirect to dnf and give user a message that it is redirecting to dnf. As for scripts, that's actually another reason why to keep yum around. Some scripts might not be able to handle some of the minor differences and some python scripts might still want to use the yum python API. That's why it makes sense to keep yum around for a few releases as a fallback. Have puppet, chef, ansible, salt, etc. been taught how to use dnf to install packages? I think it would be a shame to force all this software to do s/yum/dnf/ or to have to conditionally code for these differences based on OS release or the presense of yum vs. dnf. Why not just keep the command name the same with no nag message? I would expect puppet/chef to start using the library rather than direct access to the binary. And for ansible, I think the patch is quite simple, just add 2 lines. I guess we can start right now to get stuff merged. -- Michael Scherer -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
rfc: xserver rebase in F20 (was Re: Slipping F21)
On Wed, 2014-06-11 at 17:56 +0200, drago01 wrote: Oh and xserver really .. I am the one that gets complaints from users that I can't fix because of our ancient x11 stack. I'm not intrinsically _opposed_ to rebasing X in F20. But it's not something we've done in any previous Fedora, and there are enough nvidia users out there that I'd want to be cautious about not breaking them more than we need to. If That Other Repo doesn't have a problem with getting builds lined up for nvidia/fglrx/whatever I'd be much more willing to do X rebases in existing releases. It's still tricky for things like the xwayland/gnome lockstep, but I think we know how to handle that. - ajax -- 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: Slipping F21
On Wed, 2014-06-11 at 17:57 +0200, Jiri Eischmann wrote: Reindl Harald píše v St 11. 06. 2014 v 17:44 +0200: Am 11.06.2014 17:41, schrieb Jiri Eischmann: +1, we've already skipped one release and we just can't delay significantly more. Fedora is known as a fast-moving distribution. A large portion of our user base is using Fedora just for that reason. Do we really want to make even more of them switch to Arch? um F20 has Kernel 3.14, recent mesa, KDE 4.13 soon, recent LibreOffice and so on - what are you missing that justifies move move, go on move! Well... where do I start? For example the whole default desktop platform? Yes, we have GNOME 3.12 Copr, but it brings practical problems. The whole graphics stack also cannot be completely rebased (it would require new LLVM which would be too significant change within one release) No, actually, we rebase LLVM and Mesa in existing Fedora already. xserver and the drivers are really the only bit that stay static, and (as mentioned else-thread) that could change if we had ze vill to do so. - ajax -- 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: F22 System Wide Change: Replace Yum With DNF
On Wed, Jun 11, 2014 at 11:25:31AM -0400, Rahul Sundaram wrote: Hi On Wed, Jun 11, 2014 at 11:20 AM, Jan ZelenA 1/2 wrote: The transition period is one reason why we want to keep the name dnf. We'd basically like to keep current yum around for users that have various scripts and stuff depending on it so they have some time to migrate to dnf. I would suggest doing it the other way around.A A Rename old yum to yum-legacy.A Rename dnf to yum and at the end of the transition period drop yum-legacy and retain yum as the command line name.A A For any deprecation options, warn on them and suggest the supported alternative.A With your current plan, after the transition period, everyone has to retrain themselves to type dnf instead of yum which I don't think is necessary.A If the idea is interesting it does imply that each person having scripts depending on yum has to: * s/yum/yum-legacy/ - Deploy to prod and run as before * s/yum-legacy/dnf/ - Test and ensure it has a consistent behavior w/ yum (that the script is not using any of the deprecated options, that there is no some surprises in some weird corners) So the scripts need to be updated twice against once if we just let dnf be dnf and eventually let it provide a /usr/bin/yum optionally. Pierre -- 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: F22 System Wide Change: Replace Yum With DNF
On 06/11/2014 04:41 PM, Reindl Harald wrote: Am 11.06.2014 17:37, schrieb Chuck Anderson: Have puppet, chef, ansible, salt, etc. been taught how to use dnf to install packages? I think it would be a shame to force all this software to do s/yum/dnf/ or to have to conditionally code for these differences based on OS release or the presense of yum vs. dnf. Why not just keep the command name the same with no nag message? because it is not state of the art to change things in a way that the change is not heavily noticed to point out look we have done something and now it's your turn hopefully coreutils will not get a replacement in the next cycle with the commands move, copy, removedir, Listddir and obsolete mv, cp, rmdir, ls Good idea, they're clearer. I'll do that in the coming release. thanks, Pádraig. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Orphaned package: emacs-common-muse
Dear All, I have just orphaned the emacs-common-muse package as I don't use it, and it has been dead upstream for a few years. This package also FTBFS during the last F21 mass rebuild. I checked in a fix to enable it to build (verified with a mock build) before orphaning the package but didn't push a build, as I am happy to let it be retired before F21 branching if noone picks it up. Cheers, Jonathan. -- 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: rfc: xserver rebase in F20 (was Re: Slipping F21)
On Wed, 2014-06-11 at 17:19 +0100, Sérgio Basto wrote: On Qua, 2014-06-11 at 12:09 -0400, Adam Jackson wrote: On Wed, 2014-06-11 at 17:56 +0200, drago01 wrote: Oh and xserver really .. I am the one that gets complaints from users that I can't fix because of our ancient x11 stack. I'm not intrinsically _opposed_ to rebasing X in F20. But it's not something we've done in any previous Fedora, and there are enough nvidia users out there that I'd want to be cautious about not breaking them more than we need to. If That Other Repo doesn't have a problem with getting builds lined up for nvidia/fglrx/whatever I'd be much more willing to do X rebases in existing releases. It's still tricky for things like the xwayland/gnome lockstep, but I think we know how to handle that. Hi, why not begin by a xserver rebase in copr ? Personally, because I don't feel like doing the work twice. But if someone else wants to, sure, go for it. - ajax -- 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: rfc: xserver rebase in F20 (was Re: Slipping F21)
On Wed, Jun 11, 2014 at 6:09 PM, Adam Jackson a...@redhat.com wrote: On Wed, 2014-06-11 at 17:56 +0200, drago01 wrote: Oh and xserver really .. I am the one that gets complaints from users that I can't fix because of our ancient x11 stack. To add some context the feature that I am asking for is working DRI3 + present ... with mesa 10.2 it gives us GLX_EXT_buffer_age which finally fixes tearing issues in mutter that some user are experiencing without using workarounds like forcing the compositor to always redraw the whole screen (which costs performance and battery life). The whole effort to fix it started in January 2012 (!) so its not like it is really urgent now but given that things got fixed now (xserver 1.16, newest intel ddx snapshot, mesa 10.2) .. I rather have it on user systems at some point (and get rid of inquires on when is it going to get fixed?). I'm not intrinsically _opposed_ to rebasing X in F20. But it's not something we've done in any previous Fedora, and there are enough nvidia users out there that I'd want to be cautious about not breaking them more than we need to. If That Other Repo doesn't have a problem with getting builds lined up for nvidia/fglrx/whatever I'd be much more willing to do X rebases in existing releases. It's still tricky for things like the xwayland/gnome lockstep, but I think we know how to handle that. NVIDIA just released a driver that runs with the xserver 1.16 abi ... not sure about their legacy branches and fglrx though. -- 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: Slipping F21 (was: Schedule for Wednesday's FESCo Meeting (2014-06-11))
- Original Message - My personal opinion is that we ought to try not disrupting the release schedule. If some features miss the release train, it could wait 6 monthq (and, I disagree with dropping the whole server products). Fedora.Next is a big change in our model, our priority is to release F21 and get some feedbacks so we can adjust the plan. The thing is - server guys thinks, that without roles API it would not be Fedora.next. One can argue, that Fedora.Next is creation of products, not completion of products although. I can be for delay with a real action plan for roles framework delivery, I'd be against slipping just for we need time, we don't know how much and what we're going to do and when. In such case, it would make sense to release limited preview of Server product or even skip it for release. Probably what we need for products is the same as we do for spins - readiness checklist and we should be able if product is ready for release or not. Jaroslav Delaying F21 anymore is quite risky for us, I'd rather have a less ambitious release than getting stuck. H. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- 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: F22 System Wide Change: Replace Yum With DNF
2014-06-11 15:02 GMT+02:00 Rahul Sundaram methe...@gmail.com: I strongly agree with this for practical reasons. There is no good rationale for moving away from yum as the name of the command except some of the command line changes which happened with yum anyway (download only was added and later removed for example) and one can warn specifically for those. Yeah, if the compatibility is there, it should *just be there*. Software is here to server users, so the appropriate thing to do on (yum update) is to update the system, not to use this as an appropriate moment to essentially advertise users about a new project or about our achievements (even though the dnf project *is* an achievement, don’t get me wrong). It makes sense to only add new features to the (dnf) command, or to warn/fail when the yum compatibility doesn’t actually exist. But when the compatibility exists, the right thing for the users is to just do what was asked, no questions asked. (Structurally, this would also allow you to separate the compatibility UI hacks in /usr/bin/yum, keeping /usr/bin/dnf a bit more clean.) Mirek -- 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: F22 System Wide Change: Replace Yum With DNF
2014-06-11 16:08 GMT+02:00 drago01 drag...@gmail.com: That makes no sense. First of all if it obsoletes yum it will get pulled in during upgrades and imo it *should*. We don't really want to end up in a situation where half the users are using the default packing tool while the other half uses the old one. Precisely; such splits are always incredibly painful for everyone. Yes, it would require a more detailed contingency planning, but having upgraded and new systems use a different package manager by the same command name and the same scripts would be a troubleshooting nightmare. Mirek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
[ACTION REQUIRED] Retiring packages for Fedora 21 v2
The following packages are orphaned or did not build for two releases and will be retired when Fedora (F21) is branched, unless someone adopts them. If you know for sure that the package should be retired, please do so now with a proper reason: https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life According to https://fedoraproject.org/wiki/Schedule branching will occur not earlier than 2014-07-08. The packages will be retired shortly before. Note: If you received this mail directly you (co)maintain one of the affected packages or a package that depends on one. Package(co)maintainers === NearTree tmatsuu SteGUI orphan, pingou ale orphan, silfreed alliance chitlesh, tnorth barryorphan, gnat, vicodan bio2jack dtimms bitbake ixs blktap ke4qqq cbmc orphan, shakthimaan cgnslib orphan, chitlesh cleanfeedorphan clutter-gtkmmorphan, rhl cx18-firmwareorphan, athimm dee-qt orphan, jreznik drgeoorphan drgeo-docorphan drwright caillon eclipse-cmakeed orphan, swagiaal emacs-common-museorphan emacs-identica-mode orphan, shakthimaan eqntott orphan, chitlesh espresso-ab orphan, chitlesh fatrat orphan fatrat-subtitlesearchorphan fprint_demo orphan, pingou freetalk orphan, rishi freetalk orphan, rishi fuse-smb szpak g-wrap laxathom gdome2 orphan, sundaram gdome2 orphan, sundaram ghc-chalmers-lava2000orphan, chitlesh ghemical orphan, tolland gnomeradio orphan, itamarjp, roma guile-liblaxathom ha-jdbc orphan hdrprep orphan, silfreed inn orphan, npajkovs, ovasik, s4504kr jbosscache-core orphan, arg jbosscache-support orphan, arg jbrout orphan jcharts orphan jdbm orphan jgroups212 orphan, arg kannel thias, cicku, linuxthomass kguitar davidcornette libghemical orphan liboglappth orphan libopensync-plugin-opie awjb minbar izhar, hicham mopac7 orphan mozilla-firetray hicham mpqc orphan mule orphan nagios-plugins-check_sip orphan nesc
Re: Schedule for Wednesday's FESCo Meeting (2014-06-11)
On Wed, Jun 11, 2014 at 11:35:16AM -0400, Josh Boyer wrote: On Wed, Jun 11, 2014 at 9:36 AM, Toshio Kuratomi a.bad...@gmail.com wrote: If you would like to add something to this agenda, you can reply to this e-mail, file a new ticket at https://fedorahosted.org/fesco, e-mail me directly, or bring it up at the end of the meeting, during the open floor topic. Note that added topics may be deferred until the following meeting. Should probably discuss Bill's departure and how you want to handle the open seat. I'll make sure this comes up in the meeting and I'll open a ticket if we don't just select a runner-up from the previous election as per http://fedoraproject.org/wiki/FESCo_election_policy#Filling_Vacant_Seats -Toshio pgp3BRN4CtGOU.pgp Description: PGP signature -- 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: F22 System Wide Change: Replace Yum With DNF
2014-06-11 17:20 GMT+02:00 Jan Zelený jzel...@redhat.com: Also, dnf needs to drop all the legacy options before the transition (ie) pick erase or remove (preferably the latter) etc rather than retain all the compatibility options. The transition period is one reason why we want to keep the name dnf. The compatibility options can be kept in /usr/bin/yum without cluttering up /usr/bin/dnf. Also presenting dnf as a separate project forked from yum gives us better flexibility - for instance it's easier to drop obsoleted stuff because users don't have that high compatibility expectations. That’s a pure illusion. The users have a compatibility expectation that *their software will continue working*. Compared to asking the users to notice and work around removal of “obsoleted stuff” in /usr/bin/yum, asking the users to notice and work around removal of “obsoleted stuff” in /usr/bin/yum *and in addition to change the command name in their scripts* is, AFAICT, just making things worse. Mirek -- 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: rfc: xserver rebase in F20 (was Re: Slipping F21)
On Qua, 2014-06-11 at 12:40 -0400, Adam Jackson wrote: On Wed, 2014-06-11 at 17:19 +0100, Sérgio Basto wrote: On Qua, 2014-06-11 at 12:09 -0400, Adam Jackson wrote: On Wed, 2014-06-11 at 17:56 +0200, drago01 wrote: Oh and xserver really .. I am the one that gets complaints from users that I can't fix because of our ancient x11 stack. I'm not intrinsically _opposed_ to rebasing X in F20. But it's not something we've done in any previous Fedora, and there are enough nvidia users out there that I'd want to be cautious about not breaking them more than we need to. If That Other Repo doesn't have a problem with getting builds lined up for nvidia/fglrx/whatever I'd be much more willing to do X rebases in existing releases. It's still tricky for things like the xwayland/gnome lockstep, but I think we know how to handle that. Hi, why not begin by a xserver rebase in copr ? Personally, because I don't feel like doing the work twice. But if someone else wants to, sure, go for it. I could do it, also think about do it for eclipse-swt , but my problem is I don't know what packages I have to update , is not just xorg-x11-server , have you a list what we should update for xorg-x11-server 15.x ? -- Sérgio M. B. -- 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: Fedora 21 Mass rebuild update
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tue, 10 Jun 2014 23:49:05 +0100 Sérgio Basto ser...@serjux.com wrote: On Ter, 2014-06-10 at 17:40 -0500, Dennis Gilmore wrote: On Tue, 10 Jun 2014 23:24:41 +0100 Sérgio Basto ser...@serjux.com wrote: Hi, On Sáb, 2014-06-07 at 08:51 -0500, Dennis Gilmore wrote: [2] http://ausil.fedorapeople.org/f21-need-rebuild.html Mass rebuild stopped ? or script stopped ? Not sure what exactly you are trying to ask, Since yesterday need rebuild script says that have 1052 packages that need rebuilding, now says 1050 other script says 907 failed builds. the automatic mass rebuild has finished or not ? Yes it is finished, it was finished when i sent the email saying it was finished and merged back into rawhide. the difference in numbers will be due to packages that fail to create a srpm. they do not get as far as actually making a srpm to create a build in koji, they do not show up as failures because they failed too early. Dennis -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) iQIcBAEBAgAGBQJTmJfdAAoJEH7ltONmPFDRIQ0P/1DBch1YrT6+F3kcLrbuA+Mz d3SxR81s2w8NH+kSW0Gckh3EPbNG/EqFl/PjR/KdGvz1PUluWy0avamkzEXCIKyl F2IRJTNTy7O7a/rMpizu32T6TUq2txtf4J07fQdP5nLtZhr0BjMSkXJzc7LlTI4p XfDo43c0VO70oDAys/o1GkHcIOfdDfL4p+MSPR3HTUrkY/RzH30Aame3bqgS2iy0 F9WRO/jy6o6Q9pRNj91Ja9v6i5qKL9N0R1mBZwNCY1c26haCHnbdF/ZCpFEap6qw tPO6SNZtMK90oa1b6mvX1jneNLPSOA08U3RJNjIJQgShHrTXdI30oLa+w0CddjYP zgnFfk6pcfccYqVewojCl/7VQ8aI6WKdKOoh5W1jJpotN5O2LT8qsda3C1k5m2U3 ROXAa+4QGqmlzGPu/9ftb85aratLPeWhDYP9tIRxnWagPnC49fkz8pdYaMYHbCD8 5zqqN8Umq8GfiBn5qJ5bkOuWSRSdI3nQ5lvbO96kmyWOhk+PlyPp6IVH0er2SzR5 Zrsc1M2tCmdhhYT9MOOrVfNGFjE/7xf7GxczzcHelemEV5kUbkXX3v9mC1DtimFM /h5SMJTgZ4WT/ysyKiQv2Lan1tkYv3j14jtYJw6wNsuSN4QxwkipfyY26q2j+MXv lPkChvqWIIS0T8UIoFv4 =XBcP -END PGP SIGNATURE- -- 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: [fedora-arm] ExcludeArch tracker doesn't appear to be effective
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, 11 Jun 2014 18:03:35 +0200 drago01 drag...@gmail.com wrote: On Wed, Jun 11, 2014 at 10:14 AM, Richard W.M. Jones rjo...@redhat.com wrote: On Wed, Jun 11, 2014 at 12:07:23AM +0200, drago01 wrote: On Tue, Jun 10, 2014 at 11:52 PM, Peter Robinson pbrobin...@gmail.com wrote: [...] So moving on from that why don't you feel comfortable pointing to the ARM port? The question wasn't really directed at me but adding my 2 cents ... basically on x86(_64) hardware I can point people at fedora and most of the time it will work. As for ARM if you get a random arm hardware chances are that it is simply not supported or needs some manual hacks to get used. That's not really a fedora specific problem but it makes ARM more of a gimmick to me ... until hardware vendors catch up. As you say, mostly this is the nature of the platform. 32 bit ARM hardware is not self-describing, and not at all uniform (unlike PCs). There is no BIOS. There's no standard text display or serial port. Yeah I know but it still makes it inferior to x86_64 ... debian seems to be in a better shape simply because it supported ARM for a long time (i.e there builds for a larger set of boards). Debian is in the state its in because they build a bunch of different kernels from different sources, we have chosen not to do that but take the longer better road to use a unified kernel and support systems in a unified manner. We have been working upstream in u-boot to make things more standardised and make supporting new arm systems much much simpler. its starting to pay off with much more supportable hardware and systems that will just work in a standard fashion. debian chose to hack in support for each different system in their installer and setup/management tools. which is something we chose not to do as its really not a supportable path. Dennis -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) iQIcBAEBAgAGBQJTmJoXAAoJEH7ltONmPFDRrBsQAKPZWL/5BoQLHe3jigTZtwml N/sM0n6OgSKb28pA8d1nV1hHrKYKfTL/wFW29OL10MQAAZaTyOuQxznWzOh7yxKc NJUpbF3MVnNkX6DvJ4/HSzzF0Tb1C7BGX2vccM1+0ZFZtdTb2s6+GZ0tOKNVFD20 jT67t/DATnY8WtwL5HvuStgO5f6G0cpQerpDyCgbfBWKDQT270VxzFL/AIGHYhPx byvuOiROPqJAoHuJ9csPSKF+l5/b5S38bCYi6a2BTS06kfHmof0ct+NfIqrk11+3 ACTolPnN0Hcy2BRXglD+v4XC/KB1fCFfpb99muup7OE2fSqG0/u6yYwVEDdxWw1a j7c7YeNFSnJ1UGt+v5iUpGp97gdThuc727qb15YNhLd4nniBdShn63NxOuEk68yA wgfSd0x+dvj1aZRnYo4SMhXQOErUjNtFQYTASrkp/Qs2R6Zsza0+wYwqhFG2FZDQ ybLcwVAJthDkhAcz0Bu0xak9BQmb8z7hgggsbZWwxP04qmnG3msoTw7icVLni6UI yeaJOiKBS/7t1F9JmKdBE5susryFMYm0ESVSrOAVbKVS190IzcCxfOKGHRsPM3b/ xE8FG0wZAWgwFSgU7EZPGWQnQH1ABNlBkuTcO7Gt6+BHYo0+X+gI/LuQwAikon4g dN3tQNAohUs9kHhYheOE =33Vh -END PGP SIGNATURE- -- 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: F22 System Wide Change: Replace Yum With DNF
Forcing the users to type a different command name to get exactly the same functionality only serves to annoy the user. -- 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: F22 System Wide Change: Replace Yum With DNF
On 2014-06-11 14:07 (GMT-0400) DJ Delorie composed: Forcing the users to type a different command name to get exactly the same functionality only serves to annoy the user. And in this particular case, the change is from a nice single finger word it's a two-hander, three finger. -- The wise are known for their understanding, and pleasant words are persuasive. Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Schedule for Thursday's FPC Meeting (2014-06-12 16:00 UTC)
Following is the list of topics that will be discussed in the FPC meeting Thursday at 2014-06-12 16:00 UTC in #fedora-meeting-1 on irc.freenode.net. Local time information (via. rktime): 2014-06-12 09:00 Thu US/Pacific PDT 2014-06-12 12:00 Thu US/Eastern EDT 2014-06-12 16:00 Thu UTC - 2014-06-12 17:00 Thu Europe/London BST 2014-06-12 18:00 Thu Europe/Paris CEST 2014-06-12 18:00 Thu Europe/Berlin CEST 2014-06-12 21:30 Thu Asia/Calcutta IST --new day-- 2014-06-13 00:00 Fri Asia/Singapore SGT 2014-06-13 00:00 Fri Asia/Hong_Kong HKT 2014-06-13 01:00 Fri Asia/Tokyo JST 2014-06-13 02:00 Fri Australia/Brisbane EST Links to all tickets below can be found at: https://fedorahosted.org/fpc/report/12 = Followups = (approval and retirement sections already passed, /opt exception passed, basename passed) #topic #339 software collections in Fedora .fpc 339 https://fedorahosted.org/fpc/ticket/339 #topic #382 Go Packaging Guidelines Draft .fpc 382 https://fedorahosted.org/fpc/ticket/382 (needs to be reworded to match new .desktop wording, req. license for metadata) #topic #414 Please consider requiring AppData for all desktop applications .fpc 414 https://fedorahosted.org/fpc/ticket/414 (dots in name, utility of ruby without rails) #topic #419 ruby193 in SCL .fpc 419 https://fedorahosted.org/fpc/ticket/419 (Packaging guidlines mention it, isn't cleaned by default) #topic #435 %py3dir not removed by rpmbuild --clean .fpc 435 https://fedorahosted.org/fpc/ticket/435 = New business = #topic #436 Bundled code advise for shiboken .fpc 436 https://fedorahosted.org/fpc/ticket/436 = Open Floor = For more complete details, please visit each individual ticket. The report of the agenda items can be found at: https://fedorahosted.org/fpc/report/12 If you would like to add something to this agenda, you can reply to this e-mail, file a new ticket at https://fedorahosted.org/fpc, e-mail me directly, or bring it up at the end of the meeting, during the open floor topic. Note that added topics may be deferred until the following meeting. -- 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: [fedora-arm] ExcludeArch tracker doesn't appear to be effective--- how to improve ARM Fedora
On 06/10/2014 04:12 PM, Peter Robinson wrote: So at the moment there's around 15,000 source packages in Fedora mainline and you're getting depressed over exactly 24 of them? I'm not sure how 24 packages is providing a inconsistent experience. Fedora simply must support ARM because it ensures future viability. The progress in ARM hardware platforms is amazing---ARM device sales overtook x86 in 2010 [1] and of course the total number of ARM processors in the wild exceeds x86 by orders of magnitude. Even if we limit ourselves to 'computer' devices, ARM is significant and the numbers can only change further in ARM's favor. Limiting Fedora to x86 would condemn it to a relative or maybe even absolute gradual decline. ARM/x86 parity in Fedora was an important and correct decision, and the ARM team did great work fixing the remaining problems. ARM support came from behind, so of course there are problems remaining. My primary interest is the embedded domain---Beaglebone [2] and other tiny ARM platforms, which will arguably form the basis for the new interconnected infrastructure awkwardly called the Internet of Things (IoT). Fedora is my favorite environment, so I would like it to flourish in this space, but I have to say that Debian is a strong contender---specifically, BBB community seems to have switched to it when the original Angstrom-based software load ran out of steam. Fedora is available, but is a little bit of a work in progress [3] I think Fedora community should be aware of that and should support ARM effort even more. It seems to me that ARM platform fragmentation is a problem, due to the lack of standards in peripherals as well as boot environment. Even the Fedora build infrastructure is tricky and, as Kevin pointed out, it lags in performance---which reminds me that Linaro recently chose stripped Chromebooks 2 as its compile farm [4]. I appreciate this discussion because it focuses the need to collect and address the issues that hold ARM Fedora back. I can think of these: - fixing packages that FTBFS on ARM: - engaging packagers so that everyone cares about the issue - giving them tools to test-build with reasonable speed - keeping track of problems and working solutions - boot environment - work on a truly unified booting scheme that's as easy as x86 'stick the CD/USB in, press the button' - or at least collect enough platform-specific recipes - build environment - making sure the build environment is comprehensive and high-performance - include the most popular platforms (chromebooks, beaglebone, olimex) [1] http://www.wired.com/2012/08/ff_intel/all/ [2] BeagleBone Black (BBB) is a mint-can sized 1GHz, 512MB RAM, 4GB flash, USB/Ethernet/HDMI fully functional computer platform for the grand total of $50. It has excellent I/O interfacing capabilities, and is used for remote sensing, 3D printing and other CNC systems, etc: http://beagleboard.org/Products/BeagleBone+Black [3] http://beagleboard.org/fedora http://fedoraproject.org/wiki/Architectures/ARM/F20/Installation#For_the_BeagleBone_Black [4] http://www.systemcall.org/blog/2014/06/trashing-chromebooks/ -- 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: F22 System Wide Change: Replace Yum With DNF
On 06/11/2014 11:20 AM, Jan Zelený wrote: The transition period is one reason why we want to keep the name dnf. We'd basically like to keep current yum around for users that have various scripts and stuff depending on it so they have some time to migrate to dnf. I think this is a mistake---if dns truly provides the functionality then it should replace yum. Hopefully the majority of people can use dnf as is, but if there are corner cases that only the original yum handles, then it's better to make it available as, say, 'yum-original' or 'yum --yum-me-harder'. It boils down to this: someone is going to be inconvenienced. I argue it's better to inconvenience the minority with special 'yum' needs by making them use the 'yum-old' alias, rather than inconveniencing the majority by making everyone switch their scripts and fingers to 'dnf'. -- 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: [fedora-arm] ExcludeArch tracker doesn't appear to be effective--- how to improve ARM Fedora
Once upon a time, Przemek Klosowski przemek.klosow...@nist.gov said: Fedora simply must support ARM because it ensures future viability. The progress in ARM hardware platforms is amazing---ARM device sales overtook x86 in 2010 [1] and of course the total number of ARM processors in the wild exceeds x86 by orders of magnitude. Even if we limit ourselves to 'computer' devices, ARM is significant and the numbers can only change further in ARM's favor. Limiting Fedora to x86 would condemn it to a relative or maybe even absolute gradual decline. As has been pointed out before, sheer cores sold is a meaningless thing. MIPS and PPC outsold x86 before, and that obviously didn't condemn Fedora to irrelevance. How many ARM devices are supported by Fedora 20, as compared to the number of x86 devices supported by Fedora 20? The ARM market targeted by Fedora is very small compared to the number of x86 machines that can run F20. -- Chris Adams li...@cmadams.net -- 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: rfc: xserver rebase in F20 (was Re: Slipping F21)
To add some context the feature that I am asking for is working DRI3 + present ... with mesa 10.2 it gives us GLX_EXT_buffer_age which finally fixes tearing issues in mutter that some user are experiencing without using workarounds like forcing the compositor to always redraw the whole screen (which costs performance and battery life). There is no working DRI3 + present anywhere at all yet, or if there is it involves SNA which has its own set of not working. Dave. -- 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: rfc: xserver rebase in F20 (was Re: Slipping F21)
To add some context the feature that I am asking for is working DRI3 + present ... with mesa 10.2 it gives us GLX_EXT_buffer_age which finally fixes tearing issues in mutter that some user are experiencing without using workarounds like forcing the compositor to always redraw the whole screen (which costs performance and battery life). There is no working DRI3 + present anywhere at all yet, or if there is it involves SNA which has its own set of not working. And also DRI3 breaks a bunch of working features like gpu offload, again DRI3 + present is a keithp feature, it works on his laptop so he shipped it. It needs someone who cares to take over and finish development. Dave. -- 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: rfc: xserver rebase in F20 (was Re: Slipping F21)
On Wed, Jun 11, 2014 at 10:18 PM, David Airlie airl...@redhat.com wrote: To add some context the feature that I am asking for is working DRI3 + present ... with mesa 10.2 it gives us GLX_EXT_buffer_age which finally fixes tearing issues in mutter that some user are experiencing without using workarounds like forcing the compositor to always redraw the whole screen (which costs performance and battery life). There is no working DRI3 + present anywhere at all yet, or if there is it involves SNA which has its own set of not working. The latest intel ddx supports it using uxa (http://cgit.freedesktop.org/xorg/driver/xf86-video-intel/commit/?id=d8eb87f84f88ad2df42c6fed1d93df76589a14e3). Sna and glamor should work as well (well as well as they do using DRI2). And also DRI3 breaks a bunch of working features like gpu offload, Oh good to know. again DRI3 + present is a keithp feature, it works on his laptop so he shipped it. It needs someone who cares to take over and finish development. ugh ... has there been any discussion on this before merging it? -- 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: Slipping F21
* Reindl Harald [11/06/2014 17:44] : um F20 has Kernel 3.14, recent mesa, KDE 4.13 soon, recent LibreOffice and so on - what are you missing that justifies move move, go on move! Perl 5.20 was released in May but hasn't landed in Fedora yet (and won't until we've branched off F21 from rawhide). Emmanuel -- 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: Slipping F21
On Wed, Jun 11, 2014 at 11:14:41PM +0200, Emmanuel Seyman wrote: * Reindl Harald [11/06/2014 17:44] : um F20 has Kernel 3.14, recent mesa, KDE 4.13 soon, recent LibreOffice and so on - what are you missing that justifies move move, go on move! Perl 5.20 was released in May but hasn't landed in Fedora yet (and won't until we've branched off F21 from rawhide). So we won't get 5.20 in stable Fedora for a year? -- Tomasz Torcz Never underestimate the bandwidth of a station xmpp: zdzich...@chrome.plwagon filled with backup tapes. -- Jim Gray -- 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: [fedora-arm] ExcludeArch tracker doesn't appear to be effective--- how to improve ARM Fedora
On 06/11/2014 03:09 PM, Chris Adams wrote: Once upon a time, Przemek Klosowski przemek.klosow...@nist.gov said: Fedora simply must support ARM because it ensures future viability. The progress in ARM hardware platforms is amazing---ARM device sales overtook x86 in 2010 [1] and of course the total number of ARM processors in the wild exceeds x86 by orders of magnitude. Even if we limit ourselves to 'computer' devices, ARM is significant and the numbers can only change further in ARM's favor. Limiting Fedora to x86 would condemn it to a relative or maybe even absolute gradual decline. As has been pointed out before, sheer cores sold is a meaningless thing. MIPS and PPC outsold x86 before, and that obviously didn't condemn Fedora to irrelevance. Right, of course, and I tried to convey that it's only computers or devices that count. MIPS and PPC was never that successful for those, and ARM seems to be. I installed Linux on Android tablets, and it's useful, and will be even more useful when such devices start showing up in appliances. Android is great for a phone but not so great when you want a heavily customized system. By the way, I installed Debian because I had no idea how to start with Fedora, even though I know Fedora better and prefer it. My next project is a 7, $40 Aztek tablet: I will try to put Fedora on it! How many ARM devices are supported by Fedora 20, as compared to the number of x86 devices supported by Fedora 20? The ARM market targeted by Fedora is very small compared to the number of x86 machines that can run F20. That's a circular argument: few devices are supported because the support is weak. I believe that ARM is worth supporting in the long run and Fedora ARM should at least catch up to and then exceed Debian. -- 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: rfc: xserver rebase in F20 (was Re: Slipping F21)
Hello, On 11 June 2014 19:11, Sérgio Basto ser...@serjux.com wrote: Hi, why not begin by a xserver rebase in copr ? Personally, because I don't feel like doing the work twice. But if someone else wants to, sure, go for it. I could do it, also think about do it for eclipse-swt , but my problem is I don't know what packages I have to update , is not just xorg-x11-server , have you a list what we should update for xorg-x11-server 15.x ? Isn't this a rebuild already? http://copr.fedoraproject.org/coprs/jujuxiii/testing-fc20/ http://copr-be.cloud.fedoraproject.org/results/jujuxiii/testing-fc20/fedora-20-x86_64/ Also, any chance to see this applied in the rebuild? https://bugzilla.redhat.com/show_bug.cgi?id=1084433 Thanks, --Simone -- You cannot discover new oceans unless you have the courage to lose sight of the shore (R. W. Emerson). http://xkcd.com/229/ http://negativo17.org/ -- 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: F22 System Wide Change: Replace Yum With DNF
On Wed, 2014-06-11 at 14:18 -0400, Felix Miata wrote: On 2014-06-11 14:07 (GMT-0400) DJ Delorie composed: Forcing the users to type a different command name to get exactly the same functionality only serves to annoy the user. And in this particular case, the change is from a nice single finger word it's a two-hander, three finger. And as a user himself, above are the exact 2 reasons I hate this move. That it is better and/or becomes better due to backend and such, is no relevant (as long as its faster and easier anyway) really. Still trying to figure out why initials for a name (if decide not gonna continue to use the *yum* name) was decided, instead of at least a different name/word that makes sense at least haha -- Mike Chambers Madisonville, KY Best little town on Earth! -- 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: F22 System Wide Change: Replace Yum With DNF
On 11 June 2014 23:31, Mike Chambers m...@mtchambers.com wrote: Still trying to figure out why initials for a name (if decide not gonna continue to use the *yum* name) was decided, instead of at least a different name/word that makes sense at least haha In addition to the user confusion for the command as things stand right now in F20 dnf and yum do not share a history database. The yum history command is a very useful tool - will these databases merge or would the old history basically get lost? -- 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: Make fails with fedora build options set
On Wed, 2014-06-11 at 16:11 +0200, drago01 wrote: Another (relatively common) problem is the parallelization (-j4) tripping the makefile up. I.e. dependencies for some targets are incomplete and config.h is not yet generated when they execute. Any time this turns out to be the problem, add a comment explaining that parallel build is disabled because it causes problems. While this is an option its a kludge ... how about fix it and send the patch upstream ? Obviously better, if you *can*. :) -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- 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: [fedora-arm] ExcludeArch tracker doesn't appear to be effective
On Tue, Jun 10, 2014 at 11:29:41PM +0100, Matthew Garrett wrote:
Ok, I was entirely unaware of that, and it does change things. Thanks
for letting me know. I'll look into whether it's practical to generate a
list of all the existing ExcludeArch packages and automatically check
whether they have tracker bugs filed - does that seem helpful? It
*would* be good to have meaningful metrics on this, but I don't want
there to be excessive process overhead.
I pulled git and have the following for ExclusiveArch: %{arm}:
gda
Agda-stdlib
amplab-tachyon
avgtime
avogadro
avro
clpeak
compat-gcc-32
compat-gcc-34
cqrlog
derelict
dustmite
dyninst
elk
floppy-support
ghc-ForSyDe
gl3n
glusterfs-hadoop
grub2
grub-customizer
gtkd
hadoop
hbase
hfsplus-tools
hive
hledger
jogl
joystick-support
keepass
ldc
liveusb-creator
Macaulay2
mcollective-qpid-plugin
numactl
numad
numatop
nwchem
ocaml-cil
ocaml-gsl
patchelf
perftest
perl-Alien-ROOT
perl-qpid
perl-SOOT
pig
pure
pure-glpk
pyode
qt-creator
root
rootplot
sbt
scilab
seamonkey
solr
sparkleshare
sys_basher
tango
urjtag
wine-mono
zfs-fuse
That's 60. In addition, the following packages are ExclusiveArch: in
such a way that ARM is left out but PPC support is claimed:
gprolog
mono-bouncycastle
nant
pvs-sbcl
xsupplicant
for a total of 65. Of those:
compat-gcc32
compat-gcc34
floppy-support
grub
grub-customizer
joystick-support
liveusb-creator
numactl
numad
numatop
seem entirely legitimate. That's 55 packages, several of which can be
blamed on a small number of missing dependencies.
That's git master. In F20 the number is about the same, which I'm going
to assume means that there were some fixes and around the same number of
excludes added.
(This ignores packages that are ExclusiveArch: %ix86 x86_64 because
that's probably unfair - if the maintainer genuinely believes that it
makes sense for the package to be x86 only then that's fair)
So, two conclusions from this:
1) People are very bad at following policy here. The majority of the
packages that are marked ExcludeArch: arm are not in the tracker bug,
and most of those don't appear to have a bug filed at all.
2) The rate at which things are being fixed appears to be uninfluenced
by (1) - the number of bugs on the tracker may have increased, but the
number of packages actually excluded on ARM hasn't. This means that I
was grossly overestimating how many packages were broken. I made an
assertion without collecting accurate data first, and came to the wrong
conclusion. I apologise for that.
I'll look at filing bugs against packages that don't appear to have bugs
filed, and I'll attempt to add them to the tracker where they exist but
aren't listed.
--
Matthew Garrett | mj...@srcf.ucam.org
--
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: [fedora-arm] ExcludeArch tracker doesn't appear to be effective
On Wed, Jun 11, 2014 at 5:03 PM, Matthew Garrett mj...@srcf.ucam.org wrote: That's 60. In addition, the following packages are ExclusiveArch: in such a way that ARM is left out but PPC support is claimed: gprolog mono-bouncycastle nant pvs-sbcl xsupplicant Oh, sbcl grew ARM support yesterday. Nice! I will try to get pvs-sbcl built and tested for ARM soon. -- Jerry James http://www.jamezone.org/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
new dbus-1.8.4-1.fc21
Hi, I finally rebased dbus to the latest stable release in rawhide. I tested it lightly by upgrading a F20 cloud image to rawhide, but didn't get a chance to play around with it on a desktop system. If you see any issues, don't hesitate to file a bug. Thanks! -- 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: F21 System Wide Change: Fedora 21 Make 4.0 Update
* Jaroslav Reznik jrez...@redhat.com [2014-04-14 08:32]: = Proposed System Wide Change: Fedora 21 Make 4.0 Update = https://fedoraproject.org/wiki/Changes/F21Make40 == Detailed Description == The purpose of this update is to synchronize Fedora with the most recent Make release. The contingency for this was supposed to trigger at the Mass Rebuild. However, koji tells me that the first time Make 4.0 was built in rawhide was during the Mass Rebuild [1] :( And of course, some of the changes in Make broke other programs. OpenJDK 8, for example, currently fails to build because of this. It built for the mass rebuild (because make was not built until that point) but fails now. What's the plan here? Thanks, Omair [1] http://koji.fedoraproject.org/koji/buildinfo?buildID=525899 -- PGP Key: 66484681 (http://pgp.mit.edu/) Fingerprint = F072 555B 0A17 3957 4E95 0056 F286 F14F 6648 4681 -- 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: [ACTION REQUIRED] Retiring packages for Fedora 21 v2
On Wednesday, 11 June 2014 at 18:57, Till Maas wrote: The following packages are orphaned or did not build for two releases and will be retired when Fedora (F21) is branched, unless someone adopts them. If you know for sure that the package should be retired, please do so now with a proper reason: https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life According to https://fedoraproject.org/wiki/Schedule branching will occur not earlier than 2014-07-08. The packages will be retired shortly before. Note: If you received this mail directly you (co)maintain one of the affected packages or a package that depends on one. Package(co)maintainers === [...] cleanfeedorphan Taken. Co-maintainers welcome. [...] inn orphan, npajkovs, ovasik, s4504kr Taken. Co-maintainers welcome. Regards, Dominik -- Fedora http://fedoraproject.org/wiki/User:Rathann RPMFusion http://rpmfusion.org | MPlayer http://mplayerhq.hu Faith manages. -- Delenn to Lennier in Babylon 5:Confessions and Lamentations -- 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: Fedora 21 Mass rebuild update
* Peter Robinson pbrobin...@gmail.com [2014-06-09 11:35]: That's likely because both OpenJDK7 and OpenJDK8 both provide java-devel (based on a the repo as it stood at yesterday's compose so it doesn't include the mass rebuild packages): # repoquery --whatprovides java-devel java-1.7.0-openjdk-devel-1:1.7.0.60-2.5.0.22.pre04.fc21.x86_64 java-1.8.0-openjdk-devel-1:1.8.0.5-9.b13.fc21.x86_64 I'm sure it should likely only be provided by one or the other. No. JPackage/Fedora guidelines require all Java implementations to provide 'java-devel = version-of-java-implementation'. In practice, that means that all Java packages should require java-devel. The problem is the bytecode level. The Java compiler by default produces bytecode that is only compatible with itself or a higher version of Java. Older Java implementations error out when they see it. This is kind of opposite of what we want as a distribution, where all java bytecode should correspond with the lowest version of Java implementation that we ship. Anyway, this whole point should become moot. java-1.7.0-openjdk will be deprecated and removed from the distribution before Change Freeze. Only java-1.8.0-openjdk will be left. Thanks, Omair -- PGP Key: 66484681 (http://pgp.mit.edu/) Fingerprint = F072 555B 0A17 3957 4E95 0056 F286 F14F 6648 4681 -- 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: Fedora 21 Mass rebuild update
* Adam Jackson a...@redhat.com [2014-06-09 12:01]: In the xorg-x11-docs case it's explicitly BuildRequires: java-1.7.0-openjdk; Okay. Please don't do that. Use java-devel. Otherwise, this will break on future updates to Java 8, 9 an later ones. changing it to plain java-devel actually fixes the build, presumably because either 1.7.0 no longer provides that or yum just decides it likes 1.8.0 better. java-1.8.0-openjdk provides the highest-versioned 'java-devel' (1:1.8.0, compared with java-1.7.0's 1:1.7.0). Thanks, Omair -- PGP Key: 66484681 (http://pgp.mit.edu/) Fingerprint = F072 555B 0A17 3957 4E95 0056 F286 F14F 6648 4681 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
