Re: About libcurl, pthreads, ssl and SIGPIPE
On Tue, 2013-07-09 at 14:42 +0800, P J P wrote: > Does libcurl in Fedora use OpenSSL or a different > library for secure connections? The command you quote below seems to answer that question: > $ curl-config --configure >... '--with-libssh2' '--without-ssl' '--with-nss' ... It would seem curl is built using NSS rather than OpenSSL? -- Mathieu -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Re-review of deprecated package labyrinth and review swap
Hi Ankur, I'll take it! Best, Mario On 8 July 2013 15:37, Ankur Sinha wrote: > Hi, > > I would like to re-add labyrinth to Fedora. It was deprecated due to > multiple FTBFS bugs, but seems to build just right with the new upstream > release. > > I'd be happy to swap reviews with someone to get this package re-review > expedited :) > > The rhbz is here: > https://bugzilla.redhat.com/show_bug.cgi?id=982255 > > It should be a simple review. > -- > Thanks, > Warm regards, > Ankur (FranciscoD) > > http://fedoraproject.org/wiki/User:Ankursinha > > Join Fedora! Come talk to us! > http://fedoraproject.org/wiki/Fedora_Join_SIG > > > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel > -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: About libcurl, pthreads, ssl and SIGPIPE
On 07/09/2013 08:42 AM, P J P wrote: Till the time the new fixed version - 7.31.0 - is packaged and available, solution is for applications to ignore SIGPIPE signal. +signal(SIGPIPE, SIG_IGN); The proper fix is to use sendmsg and MSG_NOSIGNAL in the TLS implementation (in this case, NSS). -- Florian Weimer / Red Hat Product Security Team -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: About libcurl, pthreads, ssl and SIGPIPE
- Original Message - > From: Anish Patil > Subject: Re: About libcurl, pthreads, ssl and SIGPIPE > I think if you ignore SIGPIPE it produces EPIPE, try setting error no EPIPE. Nope, I see -> Program received signal SIGPIPE, Broken pipe. Thank you. --- Regards -Prasad http://feedmug.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: About libcurl, pthreads, ssl and SIGPIPE
- Original Message - > From: Mathieu Bridon > Subject: Re: About libcurl, pthreads, ssl and SIGPIPE > It would seem curl is built using NSS rather than OpenSSL? Yep, I wasn't sure if NSS is replacement for openSSL, got tricked by libssh2. Thank you! --- Regards -Prasad http://feedmug.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: About libcurl, pthreads, ssl and SIGPIPE
Hi, - Original Message - > From: Florian Weimer > Subject: Re: About libcurl, pthreads, ssl and SIGPIPE > The proper fix is to use sendmsg and MSG_NOSIGNAL in the TLS > implementation (in this case, NSS). Yeah, mostly fix has to go into SSL or NSS library, but that doesn't seem like an option. :) Thank you! --- Regards -Prasad http://feedmug.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Getting koji access for some Perl tools
Hi, folks. I've been active enough that an intro probably isn't needed, but I've not successfully worked my way through the Fedora access to manage particular packages nor have I gotten koji access. I'd particularly like to get the old "mkrdns" tool into Fedora and EPEL, since it's a personal favorite for auto-managing reverse DNS and it's very stable. Is there someone who can walk me through the Fedora koji access procedures? I've got Fedora 19 running in a VM, with access to my github repositories. I normally build my tools with "mock" for testing, but I'm happy to work with other build systems. Nico Kadel-Garcia -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
rawhide report: 20130709 changes
Compose started at Tue Jul 9 08:15:03 UTC 2013 Broken deps for x86_64 -- [derelict] derelict-tcod-3-20.20130626gite70c293.fc20.i686 requires tcod derelict-tcod-3-20.20130626gite70c293.fc20.x86_64 requires tcod derelict-tcod-devel-3-20.20130626gite70c293.fc20.i686 requires tcod derelict-tcod-devel-3-20.20130626gite70c293.fc20.x86_64 requires tcod [ekiga] ekiga-4.0.1-1.fc19.x86_64 requires libedata-book-1.2.so.17()(64bit) ekiga-4.0.1-1.fc19.x86_64 requires libcamel-1.2.so.43()(64bit) [evolution-mapi] evolution-mapi-3.9.3-1.fc20.i686 requires libcamel-1.2.so.43 evolution-mapi-3.9.3-1.fc20.x86_64 requires libcamel-1.2.so.43()(64bit) [evolution-rss] 1:evolution-rss-0.3.93-3.fc20.x86_64 requires libeutil.so()(64bit) 1:evolution-rss-0.3.93-3.fc20.x86_64 requires libeshell.so()(64bit) 1:evolution-rss-0.3.93-3.fc20.x86_64 requires libcamel-1.2.so.43()(64bit) [ffgtk] ffgtk-plugin-evolution-0.8.5-2.fc20.x86_64 requires libcamel-1.2.so.43()(64bit) [folks] 1:folks-0.9.2-3.fc20.i686 requires libcamel-1.2.so.43 1:folks-0.9.2-3.fc20.x86_64 requires libcamel-1.2.so.43()(64bit) [gdb-heap] gdb-heap-0.5-12.fc19.x86_64 requires glibc(x86-64) = 0:2.17 [giggle] giggle-0.7-3.fc20.i686 requires libcamel-1.2.so.43 giggle-0.7-3.fc20.x86_64 requires libcamel-1.2.so.43()(64bit) [glabels] glabels-3.0.1-8.fc20.x86_64 requires libcamel-1.2.so.43()(64bit) [gnome-contacts] gnome-contacts-3.8.2-2.fc20.x86_64 requires libcamel-1.2.so.43()(64bit) [gnome-phone-manager] gnome-phone-manager-0.68-11.fc20.x86_64 requires libcamel-1.2.so.43()(64bit) gnome-phone-manager-telepathy-0.68-11.fc20.x86_64 requires libcamel-1.2.so.43()(64bit) [gnome-shell] gnome-shell-3.9.2-1.fc20.x86_64 requires libcamel-1.2.so.43()(64bit) [gooddata-cl] gooddata-cl-1.2.56-2.fc19.noarch requires gdata-java [gr-air-modes] gr-air-modes-0-0.13.20130409gitf25d21f5.fc20.i686 requires libgruel-3.6.5.so.0.0.0 gr-air-modes-0-0.13.20130409gitf25d21f5.fc20.i686 requires libgnuradio-core-3.6.5.so.0.0.0 gr-air-modes-0-0.13.20130409gitf25d21f5.fc20.x86_64 requires libgruel-3.6.5.so.0.0.0()(64bit) gr-air-modes-0-0.13.20130409gitf25d21f5.fc20.x86_64 requires libgnuradio-core-3.6.5.so.0.0.0()(64bit) [gr-osmosdr] gr-osmosdr-0.0.1-3.20130403gite85c68d9.fc20.i686 requires libgruel-3.6.5.so.0.0.0 gr-osmosdr-0.0.1-3.20130403gite85c68d9.fc20.i686 requires libgnuradio-fcd-3.6.5.so.0.0.0 gr-osmosdr-0.0.1-3.20130403gite85c68d9.fc20.i686 requires libgnuradio-core-3.6.5.so.0.0.0 gr-osmosdr-0.0.1-3.20130403gite85c68d9.fc20.x86_64 requires libgruel-3.6.5.so.0.0.0()(64bit) gr-osmosdr-0.0.1-3.20130403gite85c68d9.fc20.x86_64 requires libgnuradio-fcd-3.6.5.so.0.0.0()(64bit) gr-osmosdr-0.0.1-3.20130403gite85c68d9.fc20.x86_64 requires libgnuradio-core-3.6.5.so.0.0.0()(64bit) gr-osmosdr-devel-0.0.1-3.20130403gite85c68d9.fc20.i686 requires pkgconfig(gnuradio-core) gr-osmosdr-devel-0.0.1-3.20130403gite85c68d9.fc20.x86_64 requires pkgconfig(gnuradio-core) [gtkd] gtkd-2.0.0-29.20120815git9ae9181.fc18.i686 requires libphobos-ldc.so.60 gtkd-2.0.0-29.20120815git9ae9181.fc18.x86_64 requires libphobos-ldc.so.60()(64bit) [jana] jana-0.4.5-0.31.20100520gitacd72f2.fc20.i686 requires libcamel-1.2.so.43 jana-0.4.5-0.31.20100520gitacd72f2.fc20.x86_64 requires libcamel-1.2.so.43()(64bit) [jboss-as] jboss-as-7.1.1-19.fc20.noarch requires cxf-common >= 0:2.6.3 [kawa] 1:kawa-1.11-5.fc19.x86_64 requires servlet25 [koji] koji-vm-1.8.0-1.fc20.noarch requires python-virtinst [kyua-cli] kyua-cli-0.5-3.fc19.x86_64 requires liblutok.so.0()(64bit) kyua-cli-tests-0.5-3.fc19.x86_64 requires liblutok.so.0()(64bit) [lancet] lancet-1.0.1-6.fc19.noarch requires ant-nodeps >= 0:1.7.1 [libopensync-plugin-evolution2] 1:libopensync-plugin-evolution2-0.22-34.fc20.x86_64 requires libcamel-1.2.so.43()(64bit) [mail-notification] mail-notification-evolution-plugin-5.4-72.git.eab5c13.fc20.x86_64 requires libcamel-1.2.so.43()(64bit) [nifti2dicom] nifti2dicom-0.4.6-1.fc20.x86_64 requires libitksys-4.3.so.1()(64bit) nifti2dicom-0.4.6-1.fc20.x86_64 requires libitkopenjpeg-4.3.so.1()(64bit) nifti2dicom-0.4.6-1.fc20.x86_64 requires libitkNetlibSlatec-4.3.so.1()(64bit) nifti2dicom-0.4.6-1.fc20.x86_64 requires libITKznz-4.3.so.1()(64bit) nifti2dicom-0.4.6-1.fc20.x86_64 requires libITKniftiio-4.3.so.1()(64bit) nifti2dicom-0.4.6-1.fc20.x86_64 requires libITKgiftiio-4.3.so.1()(64bit) nifti2dicom-0.4.6-1.fc20.x86_64 requires libITKWatersheds-4.3.so.1()(64bit) nifti2dicom-0.4.6-1.fc20.x86_64 requires libITKVideoIO-4.3.so.1()(64bit) nifti2dicom-
Manual page for Shared-System-Certificates feature
A manual page is now available that describes the new Shared-System-Certificates feature. It's contained in this new build for F19: https://admin.fedoraproject.org/updates/ca-certificates-2012.87-10.4.fc19 (and in rahide, too). man update-ca-trust Please let us know if you have feedback. Thanks a lot in advance! Kai -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Manual page for Shared-System-Certificates feature
On 09.07.2013 15:30, Kai Engert wrote: > A manual page is now available that describes the new > Shared-System-Certificates feature. > > It's contained in this new build for F19: > https://admin.fedoraproject.org/updates/ca-certificates-2012.87-10.4.fc19 > (and in rahide, too). > > man update-ca-trust > > Please let us know if you have feedback. Please keep in mind that this documents things for Fedora 19. For Fedora 20 we aim to have simple tools to globally add and remove anchors and modify the blacklist. All the best, Stef -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
F20 System Wide Change: ARM as primary Architecture
= Proposed System Wide Change: ARM as primary Architecture = https://fedoraproject.org/wiki/Changes/ARM_as_Primary Change owner(s): Dennis Gilmore , Peter Robinson Make ARM a primary architecture. Add armv7hl to the i686 and x86_64 as arches that we build and support. This will mean that all packages supported by the ARM architecture must build for ARM to be released. With the release of Fedora 19 we have deprecated support for software floating support (ARMv5tel sfp) so the only proposed addition to primary architectures is currently ARMv7 hardware floating point 32 bit support (ARMv7 hfp 32bit). == Detailed description == The Changing IT landscape has started to focus on greener technologies as well as cheaper mass produced devices that allow for fully functional cheap devices for lower socio-economic areas and other markets like education and "makers". ARM SoCs have traditionally been the domain of embedded and mobile applications but are now finding their way into more traditional computing devices like desktop, notebook and server markets. Fedora ARM currently works on many different devices with wider support coming with each new mainline kernel release. For this change we will enable armv7hl builds on primary koji, and compose arm trees as with the other primary architectures. Fedora has in the Phoenix data centre 96 quad core Calxeda EnergyCore server nodes. Some of these nodes will remain allocated to the arm secondary architecture koji instance for building updates for the current Fedora 18 and 19 releases. When Fedora 18 goes end of life the ARMv5 softfp nodes will able to be be reallocated to other tasks. Infrastructure has expressed an interest in testing and experimenting with some of its workloads on ARM, some are allocated to QA and some for releng. There is currently 24 nodes configured in primary koji ready to go as builders, there is the capacity to add up to 24 more when ARM becomes primary if desired. The kernel is now a multi platform unified ARMv7 kernel supporting a number of SoCs with support expanding with each new upstream release. We build a base and LPAE variant similar to i686. There is an ARM specific (ARMv7 and aarch64) kernel maintainer working in collaboration with the Fedora kernel team. The releases are composed using the exact same tooling as used for the primary architectures. Disk images for development boards are generated by appliance- creator and the kickstarts live in spin-kickstarts, they take a similar format as the livecds on primary but are shipped as an OEM disk image, and like primary initial-setup is used to do final user configuration. Like primary pungi is used to generate an install tree, PXE install trees are created but current bootloaders don't support isofs so ISO images aren't currently created. == Scope == Add armv7hl to list of arches for f20-build and future build tags in koji compose armhfp trees with i386 and x86_64. Requisite build hardware already exists in phx2 and is configured to work with mainline koji. Proposal owners: change the arches in koji, import the matching ARMv7 rawhide builds into koji. Update Release Engineering scripts to automatically build armhfp trees along with i686 and x86_64. Other developers: submit builds as normal, in the event of unexpected build failures liaise with the ARM Team to help debug and fix issues. Release engineering: Will need to add armhfp to the release processes and make arm install trees and disk images with each milestone compose. Release Engineering are part of the team of people proposing the Change. Policies and guidelines: armv7hl builds will be required to complete for builds to be successful in koji ___ 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
Re: Re-review of deprecated package labyrinth and review swap
On Tue, 2013-07-09 at 09:12 +0200, Mario Ceresa wrote: > Hi Ankur, > I'll take it! Thanks Mario! Labyrinth has been re-added to the repositories. I'll push builds soon. -- Thanks, Warm regards, Ankur (FranciscoD) http://fedoraproject.org/wiki/User:Ankursinha Join Fedora! Come talk to us! http://fedoraproject.org/wiki/Fedora_Join_SIG signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: ARM as primary Architecture
Excellent proposal. I of course think this would be just awesome! -- Sent from my iPad On Jul 9, 2013, at 15:37, Jaroslav Reznik wrote: > = Proposed System Wide Change: ARM as primary Architecture = > https://fedoraproject.org/wiki/Changes/ARM_as_Primary > > Change owner(s): Dennis Gilmore , Peter Robinson > > > Make ARM a primary architecture. Add armv7hl to the i686 and x86_64 as arches > that we build and support. This will mean that all packages supported by the > ARM architecture must build for ARM to be released. With the release of > Fedora > 19 we have deprecated support for software floating support (ARMv5tel sfp) so > the only proposed addition to primary architectures is currently ARMv7 > hardware floating point 32 bit support (ARMv7 hfp 32bit). > > == Detailed description == > The Changing IT landscape has started to focus on greener technologies as > well > as cheaper mass produced devices that allow for fully functional cheap > devices > for lower socio-economic areas and other markets like education and "makers". > ARM SoCs have traditionally been the domain of embedded and mobile > applications but are now finding their way into more traditional computing > devices like desktop, notebook and server markets. Fedora ARM currently works > on many different devices with wider support coming with each new mainline > kernel release. > > For this change we will enable armv7hl builds on primary koji, and compose > arm > trees as with the other primary architectures. Fedora has in the Phoenix data > centre 96 quad core Calxeda EnergyCore server nodes. Some of these nodes will > remain allocated to the arm secondary architecture koji instance for building > updates for the current Fedora 18 and 19 releases. When Fedora 18 goes end of > life the ARMv5 softfp nodes will able to be be reallocated to other tasks. > Infrastructure has expressed an interest in testing and experimenting with > some of its workloads on ARM, some are allocated to QA and some for releng. > There is currently 24 nodes configured in primary koji ready to go as > builders, > there is the capacity to add up to 24 more when ARM becomes primary if > desired. > > The kernel is now a multi platform unified ARMv7 kernel supporting a number > of > SoCs with support expanding with each new upstream release. We build a base > and LPAE variant similar to i686. There is an ARM specific (ARMv7 and > aarch64) > kernel maintainer working in collaboration with the Fedora kernel team. The > releases are composed using the exact same tooling as used for the primary > architectures. Disk images for development boards are generated by appliance- > creator and the kickstarts live in spin-kickstarts, they take a similar > format > as the livecds on primary but are shipped as an OEM disk image, and like > primary initial-setup is used to do final user configuration. Like primary > pungi > is used to generate an install tree, PXE install trees are created but > current > bootloaders don't support isofs so ISO images aren't currently created. > > == Scope == > Add armv7hl to list of arches for f20-build and future build tags in koji > compose armhfp trees with i386 and x86_64. Requisite build hardware already > exists in phx2 and is configured to work with mainline koji. > > Proposal owners: change the arches in koji, import the matching ARMv7 rawhide > builds into koji. Update Release Engineering scripts to automatically build > armhfp trees along with i686 and x86_64. > > Other developers: submit builds as normal, in the event of unexpected build > failures liaise with the ARM Team to help debug and fix issues. > > Release engineering: Will need to add armhfp to the release processes and > make > arm install trees and disk images with each milestone compose. Release > Engineering are part of the team of people proposing the Change. > > Policies and guidelines: armv7hl builds will be required to complete for > builds to be successful in koji > ___ > 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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
How to remove auto generated python dependency?
Hi, A package I maintain (mc) has two rarely-used python scripts. Since they have #!/usr/bin/python header, build machinery automatically adds python dependency. But I don't want this to happen - the program is very much usable without python too. Requiring python pulls in a top of other stuff which isn't needed. How can I suppress this in the specfile? AutoReqProv seems to be a too strong medicine - I would like to blacklist only python dep. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: How to remove auto generated python dependency?
On Tue, Jul 09, 2013 at 05:26:19PM +0200, Denys Vlasenko wrote: > Hi, > > A package I maintain (mc) has two rarely-used > python scripts. > > Since they have #!/usr/bin/python header, build machinery > automatically adds python dependency. > > But I don't want this to happen - the program is very much > usable without python too. Requiring python pulls in a top > of other stuff which isn't needed. Are those scripts installed into /usr/bin ? If so then, IMHO, removing the python dependency is not appropriate, regardless of whether the scripts are used frequently or not. Splitting them out into a sub-RPM might be a more suitable approach. > How can I suppress this in the specfile? > > AutoReqProv seems to be a too strong medicine - I would like > to blacklist only python dep. You can filter the provides/requires with a regex: https://fedoraproject.org/wiki/Packaging:AutoProvidesAndRequiresFiltering#Filtering_provides_and_requires_after_scanning Daniel -- |: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[perl-Module-Build-Tiny/f19] (4 commits) ...Update to 0.024
Summary of changes: 638d8c6... Update to 0.021 (*) 3532187... Update to 0.022 (*) d060950... Update to 0.023 (*) 3d58630... Update to 0.024 (*) (*) This commit already existed in another branch; no separate mail sent -- 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: [Owner-change] Fedora packages ownership change
On 07/09/2013 12:16 AM, Vít Ondruch wrote: Dne 8.7.2013 12:00, nob...@fedoraproject.org napsal(a): ruby-mysql [devel] was orphaned by orion A Ruby interface to MySQL https://admin.fedoraproject.org/pkgdb/acls/name/ruby-mysql Was this intentional? There is no replacement to this package in Fedora yet, nor it was correctly deprecated. Nothing uses it that I can see. rubygem-mysql2 is under review: https://bugzilla.redhat.com/show_bug.cgi?id=974889 and that should be used going forward. If someone really wants to resurrect this, I would suggest using this: http://www.cora.nwra.com/~orion/fedora/rubygem-mysql-2.9.1-1.fc19.src.rpm -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 http://www.nwra.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: How to remove auto generated python dependency?
On 07/09/2013 05:30 PM, Michal Schmidt wrote: > On 07/09/2013 05:26 PM, Denys Vlasenko wrote: >> Since they have #!/usr/bin/python header, build machinery >> automatically adds python dependency. >> >> But I don't want this to happen - the program is very much >> usable without python too. Requiring python pulls in a top >> of other stuff which isn't needed. >> >> How can I suppress this in the specfile? > > This page should help: > http://fedoraproject.org/wiki/Packaging:AutoProvidesAndRequiresFiltering Thanks, looks like what I needed! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Getting koji access for some Perl tools
Hi Nico, On Tue, Jul 09, 2013 at 06:06:38AM -0400, Nico Kadel-Garcia wrote: > I've been active enough that an intro probably isn't needed, but I've > not successfully worked my way through the Fedora access to manage > particular packages nor have I gotten koji access. I'd particularly > like to get the old "mkrdns" tool into Fedora and EPEL, since it's a > personal favorite for auto-managing reverse DNS and it's very stable. > > Is there someone who can walk me through the Fedora koji access > procedures? I've got Fedora 19 running in a VM, with access to my > github repositories. I normally build my tools with "mock" for > testing, but I'm happy to work with other build systems. to get koji build access you need to become a package maintainer as described here: https://fedoraproject.org/wiki/Join_the_package_collection_maintainers Essentially you need to create a spec/SRPM for the package, upload it to Bugzilla and find a sponsor that reviews the files. Then you will become a package maintainer and get koji access as well. To find a sponsor it is usually helpful to show your knowledge to the process and the packaging guidelines by preliminary reviewing other peoples specs/SRPMs on Bugzilla. I hope the complex procedure does not repel you and you still like to get the package into Fedora. :-) If you have further questions, please ask. If you did some preliminary reviews and do not find a sponsor, you can write me directly and I will see what I can do as time permits. Regards Till -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [Owner-change] Fedora packages ownership change
On Mon, Jul 08, 2013 at 10:00:04AM +, nob...@fedoraproject.org wrote: > Change in ownership over the last 168 hours > === To whoever is creating these messages: Please add a message about who is responsible for these reports, where to report bugs and where the sources of the script can be found. Thank you Till -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Orphaning packages: PySolFC* and lybniz
On 2013-07-06 8:20 PM, Marcelo Barbosa - Fedora Ambassador wrote: Stewart, I can keep these packages, how to apply ? How should I proceed ? Regards Marcelo Barbosa Hi Marcelo, Great! Please sign-in to the Package DB and claim ownership of the package's branches you wish to maintain. More information is available here: http://fedoraproject.org/wiki/Orphaned_package_that_need_new_maintainers#Claiming_Ownership_of_an_Orphaned_Package_Procedure For your convenience, here are direct links to the package DB entries: * https://admin.fedoraproject.org/pkgdb/acls/name/lybniz * https://admin.fedoraproject.org/pkgdb/acls/name/PySolFC * https://admin.fedoraproject.org/pkgdb/acls/name/PySolFC-cardsets * https://admin.fedoraproject.org/pkgdb/acls/name/PySolFC-music Regards, Stewart -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: How to remove auto generated python dependency?
On Tue, Jul 09, 2013 at 04:37:40PM +0100, Daniel P. Berrange wrote: > On Tue, Jul 09, 2013 at 05:26:19PM +0200, Denys Vlasenko wrote: > > Hi, > > > > A package I maintain (mc) has two rarely-used > > python scripts. > > > > Since they have #!/usr/bin/python header, build machinery > > automatically adds python dependency. > > > > But I don't want this to happen - the program is very much > > usable without python too. Requiring python pulls in a top > > of other stuff which isn't needed. > > Are those scripts installed into /usr/bin ? If so then, IMHO, > removing the python dependency is not appropriate, regardless > of whether the scripts are used frequently or not. Splitting > them out into a sub-RPM might be a more suitable approach. > -- If this is a Fedora package, then a subpackage is definitely the way to go. Filtering out a dependency that is actually present would be introducing a bug. -Toshio pgpQswRvhX80Y.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [Owner-change] Fedora packages ownership change
On Mon, Jul 08, 2013 at 10:00:04AM +, nob...@fedoraproject.org wrote: > Change in ownership over the last 168 hours How about changing the report time to to last 48-216 hours, then ongoing ownership transfers would be recognised as long as they happen within 48 hours. Regards Till -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: How to remove auto generated python dependency?
On 07/09/2013 05:26 PM, Denys Vlasenko wrote: Since they have #!/usr/bin/python header, build machinery automatically adds python dependency. But I don't want this to happen - the program is very much usable without python too. Requiring python pulls in a top of other stuff which isn't needed. How can I suppress this in the specfile? This page should help: http://fedoraproject.org/wiki/Packaging:AutoProvidesAndRequiresFiltering -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Schedule for Wednesday's FESCo Meeting (2013-07-10)
Note: As of this writing, the agenda for this week is very light. The one known agenda item is waiting on information which hasn't been submitted yet. If you have something to discuss, please reply to this e-mail ASAP so we can discuss it in the meeting. If we don't get more information on the one agenda item or other things people want to discuss we may cancel the meeting. Thanks for your participation! -Toshio Following is the list of topics that will be discussed in the FESCo meeting Wednesday at 18: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 '-MM-DD HH:MM UTC' Links to all tickets below can be found at: https://fedorahosted.org/fesco/report/9 = Followups = #topic #1132 libtool + %global _hardened_build 1 = no full hardening .fesco 1132 https://fedorahosted.org/fesco/ticket/1132 = New business = = 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. pgpMEB2kNltff.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Requesting provenpackager help
Hi, I need lazarus in F19 to be rebuilt because the current version was built against an old Free Pascal Compiler version and doesn't work with the newer. There's nothing to be changed in spec file, just a rebuild is needed (and to push the update to stable or creating an override in koji). Is there any provenpackager that can take care of this? See https://bugzilla.redhat.com/show_bug.cgi?id=964256 for reference. Thank you. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: ARM as primary Architecture
nnnOn Tue, Jul 9, 2013 at 3:00 PM, Jaroslav Reznik wrote: > = Proposed System Wide Change: ARM as primary Architecture = > https://fedoraproject.org/wiki/Changes/ARM_as_Primary How many F19 packages currently fail to build (or are excluded but shouldn't be) on ARM? How do we stand against the other items of https://fedoraproject.org/wiki/Secondary_Architecture_Promotion_Requirements ? Mirek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [Owner-change] Fedora packages ownership change
On Tue, 2013-07-09 at 18:06 +0200, Till Maas wrote: > On Mon, Jul 08, 2013 at 10:00:04AM +, nob...@fedoraproject.org wrote: > > Change in ownership over the last 168 hours > > === > > To whoever is creating these messages: That would be me (and infra) > Please add a message about who is responsible for these reports, where > to report bugs Sounds good. > and where the sources of the script can be found. That would be there: https://github.com/pypingou/fedora-owner-change Pierre -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: ARM as primary Architecture
On Tue, Jul 9, 2013 at 5:54 PM, Miloslav Trmač wrote: > nnnOn Tue, Jul 9, 2013 at 3:00 PM, Jaroslav Reznik wrote: >> = Proposed System Wide Change: ARM as primary Architecture = >> https://fedoraproject.org/wiki/Changes/ARM_as_Primary > > How many F19 packages currently fail to build (or are excluded but > shouldn't be) on ARM? How do we stand against the other items of > https://fedoraproject.org/wiki/Secondary_Architecture_Promotion_Requirements At F-19 gold we were missing around 233 source packages out of around 13,500 total. These are broken down into a couple of groups: - Non ARM packages (x86/PPC/s390) - Languages not currerntly supported on ARM - eg D, a fpc and a few others - Packages that have issues with their CFLAGS (and actually should be fine if they used distro flags like they should) - Random other problems. I'm planning on going through these again and document the remaining packages. Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: ARM as primary Architecture
On Tue, Jul 9, 2013 at 12:54 PM, Miloslav Trmač wrote: > nnnOn Tue, Jul 9, 2013 at 3:00 PM, Jaroslav Reznik wrote: >> = Proposed System Wide Change: ARM as primary Architecture = >> https://fedoraproject.org/wiki/Changes/ARM_as_Primary > > How many F19 packages currently fail to build (or are excluded but > shouldn't be) on ARM? How do we stand against the other items of > https://fedoraproject.org/wiki/Secondary_Architecture_Promotion_Requirements > ? I'm particularly curious about the developer resources and release criteria items. The proposal calls out one kernel maintainer, which is great, but doesn't expand on how many others are doing ARM work. Is the ARM team on the hook to go through all of the existing QA criteria on ARM platforms and do they have enough resources to do this? I have a secondary concern on kernel build times. It's greatly improved on the newer hardware, but a primary kernel build takes ~ 1hr 45min. An ARM build, which doesn't even build the -debug variants, still takes ~4 to 4.5hrs. Are other larger packages (gcc, etc) similarly significantly slower still? How much delay ARM adds to a build is certainly up for discussion but it would be good to have numbers showing the average additional time required per package and the worst case outliers. josh -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Requesting provenpackager help
On Ter, 2013-07-09 at 18:48 +0200, Mattia Verga wrote: > Hi, > I need lazarus in F19 to be rebuilt because the current version was > built against an old Free Pascal Compiler version and doesn't work with > the newer. +1 I need it too > There's nothing to be changed in spec file, just a rebuild is needed > (and to push the update to stable or creating an override in koji). Is > there any provenpackager that can take care of this? > > See https://bugzilla.redhat.com/show_bug.cgi?id=964256 for reference. Thanks, -- Sérgio M. B. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [Owner-change] Fedora packages ownership change
On Tue, 2013-07-09 at 18:23 +0200, Till Maas wrote: > On Mon, Jul 08, 2013 at 10:00:04AM +, nob...@fedoraproject.org wrote: > > Change in ownership over the last 168 hours > > How about changing the report time to to last 48-216 hours, then ongoing > ownership transfers would be recognised as long as they happen within 48 > hours. 168 hours is a week, so ownership transfer should be picked if they happen within a week. You would like to have it down to 48h or up to 216h? The problem is to not become to spammy while remaining informative, so we went for 1 week, this can be adjusted of course. Pierre -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [Owner-change] Fedora packages ownership change
On Tue, 2013-07-09 at 18:06 +0200, Till Maas wrote: > On Mon, Jul 08, 2013 at 10:00:04AM +, nob...@fedoraproject.org wrote: > > Change in ownership over the last 168 hours > > === > > To whoever is creating these messages: > Please add a message about who is responsible for these reports, where > to report bugs and where the sources of the script can be found. >From next week the report will have a link to the sources (the git repo). Pierre -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [Owner-change] Fedora packages ownership change
On Mon, 2013-07-01 at 21:25 +0200, Pierre-Yves Chibon wrote: > On Mon, 2013-07-01 at 20:48 +0200, Michael Schwendt wrote: > > On Mon, 1 Jul 2013 18:14:46 + (UTC), nobody fedoraproject org wrote: > > > > > 9 packages were orphaned > > > > > php-pecl-apc [devel] was orphaned by remi > > > APC caches and optimizes PHP intermediate code > > > https://admin.fedoraproject.org/pkgdb/acls/name/php-pecl-apc > > > > Could the script be enhanced to distinguish between "orphaned" and > > "deprecated" (= retired)? > > > > For orphans in pkgdb any packager can simply click the "Take ownership" > > button. For retired packages, the process is different, and there may be a > > good reason why a package has been retired/dropped/replaced/… > > fedmsg announce them so we should be able to indeed. > So we'll have: > - orphaned > - unorphaned > - retired > - changed This is adjusted and will be in the report of next week. Pierre -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: ARM as primary Architecture
On 9 July 2013 10:57, Peter Robinson wrote: > On Tue, Jul 9, 2013 at 5:54 PM, Miloslav Trmač wrote: > > nnnOn Tue, Jul 9, 2013 at 3:00 PM, Jaroslav Reznik > wrote: > >> = Proposed System Wide Change: ARM as primary Architecture = > >> https://fedoraproject.org/wiki/Changes/ARM_as_Primary > > > > How many F19 packages currently fail to build (or are excluded but > > shouldn't be) on ARM? How do we stand against the other items of > > > https://fedoraproject.org/wiki/Secondary_Architecture_Promotion_Requirements > > At F-19 gold we were missing around 233 source packages out of around > 13,500 total. These are broken down into a couple of groups: > - Non ARM packages (x86/PPC/s390) > - Languages not currerntly supported on ARM - eg D, a fpc and a few others > - Packages that have issues with their CFLAGS (and actually should be > fine if they used distro flags like they should) > - Random other problems. > > I'm planning on going through these again and document the remaining > packages. > > How do we treat "Desktop" items where the package compiles fine but does not run well without external drivers (the GNOME on ARM conversation earlier ) Or am I misreading that conversation. -- Stephen J Smoogen. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: ARM as primary Architecture
On Tue, Jul 09, 2013 at 01:00:27PM -0400, Josh Boyer wrote: > >> = Proposed System Wide Change: ARM as primary Architecture = > >> https://fedoraproject.org/wiki/Changes/ARM_as_Primary > > > > How many F19 packages currently fail to build (or are excluded but > > shouldn't be) on ARM? How do we stand against the other items of > > https://fedoraproject.org/wiki/Secondary_Architecture_Promotion_Requirements > > ? > > I'm particularly curious about the developer resources and release > criteria items. The proposal calls out one kernel maintainer, which > is great, but doesn't expand on how many others are doing ARM work. > Is the ARM team on the hook to go through all of the existing QA > criteria on ARM platforms and do they have enough resources to do > this? > I wouldn't limit the things I'm willing to fix to the kernel. I'll happily look into all ARM FTBFS. --Kyle -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: ARM as primary Architecture
> On 9 July 2013 10:57, Peter Robinson wrote: >> >> On Tue, Jul 9, 2013 at 5:54 PM, Miloslav Trmač wrote: >> > nnnOn Tue, Jul 9, 2013 at 3:00 PM, Jaroslav Reznik >> > wrote: >> >> = Proposed System Wide Change: ARM as primary Architecture = >> >> https://fedoraproject.org/wiki/Changes/ARM_as_Primary >> > >> > How many F19 packages currently fail to build (or are excluded but >> > shouldn't be) on ARM? How do we stand against the other items of >> > >> > https://fedoraproject.org/wiki/Secondary_Architecture_Promotion_Requirements >> >> At F-19 gold we were missing around 233 source packages out of around >> 13,500 total. These are broken down into a couple of groups: >> - Non ARM packages (x86/PPC/s390) >> - Languages not currerntly supported on ARM - eg D, a fpc and a few others >> - Packages that have issues with their CFLAGS (and actually should be >> fine if they used distro flags like they should) >> - Random other problems. >> >> I'm planning on going through these again and document the remaining >> packages. >> > > How do we treat "Desktop" items where the package compiles fine but does not > run well without external drivers (the GNOME on ARM conversation earlier ) > Or am I misreading that conversation. The same way as we do now. In some cases there are drivers but they're still in development and not stable (tegra/lima/freedreno), or there's third party binary drivers (like mainline with the nVidia binary drivers). The situation is improving rapidly for the 2D/3D accelerated situation and in the mean time there are numerous other desktops that run perfectly well. In time I'm sure we'll get to 100% parity with the mainline platform but I don't believe anyone believes we're there now but I don't see that as a blocker either. Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: ARM as primary Architecture
On Tue, Jul 9, 2013 at 6:24 PM, Kyle McMartin wrote: > On Tue, Jul 09, 2013 at 01:00:27PM -0400, Josh Boyer wrote: >> >> = Proposed System Wide Change: ARM as primary Architecture = >> >> https://fedoraproject.org/wiki/Changes/ARM_as_Primary >> > >> > How many F19 packages currently fail to build (or are excluded but >> > shouldn't be) on ARM? How do we stand against the other items of >> > https://fedoraproject.org/wiki/Secondary_Architecture_Promotion_Requirements >> > ? >> >> I'm particularly curious about the developer resources and release >> criteria items. The proposal calls out one kernel maintainer, which >> is great, but doesn't expand on how many others are doing ARM work. >> Is the ARM team on the hook to go through all of the existing QA >> criteria on ARM platforms and do they have enough resources to do >> this? >> > > I wouldn't limit the things I'm willing to fix to the kernel. I'll > happily look into all ARM FTBFS. There's a number of people working on this but ultimately like all problems we can handle as much as possible but we also need assistance by the package maintainers themselves. Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: ARM as primary Architecture
On Tue, 2013-07-09 at 18:31 +0100, Peter Robinson wrote: > > How do we treat "Desktop" items where the package compiles fine but does not > > run well without external drivers (the GNOME on ARM conversation earlier ) > > Or am I misreading that conversation. > > The same way as we do now. In some cases there are drivers but they're > still in development and not stable (tegra/lima/freedreno), or there's > third party binary drivers (like mainline with the nVidia binary > drivers). The situation is improving rapidly for the 2D/3D accelerated > situation and in the mean time there are numerous other desktops that > run perfectly well. In time I'm sure we'll get to 100% parity with the > mainline platform but I don't believe anyone believes we're there now > but I don't see that as a blocker either. I disagree with that. I'd at least want to see a plan for how we plan to address the graphics situation. If the answer is that we have to live with software rendering for now, then we should have somebody working on making llvm work on arm again. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: ARM as primary Architecture
On Tue, Jul 09, 2013 at 06:33:53PM +0100, Peter Robinson wrote: > There's a number of people working on this but ultimately like all > problems we can handle as much as possible but we also need assistance > by the package maintainers themselves. No, that's not how it works. While you're a secondary architecture you get to take responsibility for making stuff work yourself. If a package maintainer is willing to volunteer time and effort to making things work then that's a bonus, but if they're not then someone who cares about ARM has to take responsibility. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: ARM as primary Architecture
On Tue, Jul 9, 2013 at 6:43 PM, Matthew Garrett wrote: > On Tue, Jul 09, 2013 at 06:33:53PM +0100, Peter Robinson wrote: > >> There's a number of people working on this but ultimately like all >> problems we can handle as much as possible but we also need assistance >> by the package maintainers themselves. > > No, that's not how it works. While you're a secondary architecture you > get to take responsibility for making stuff work yourself. If a package > maintainer is willing to volunteer time and effort to making things work > then that's a bonus, but if they're not then someone who cares about ARM > has to take responsibility. That's correct and you'll find that that's what I've been doing for 2.5+ years now, but we're talking about Primary here... and in primary it's everyone's responsibility... BTW where's the secondary bit documented? Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: ARM as primary Architecture
llvmpipe has been known to be broken for months, and nobody on the ARM team appears capable of fixing it. As a result, ARM shipped in F19 without any out of the box support for running our default desktop. This doesn't make it seem like the ARM port currently has sufficient developer expertise involved, and I'd really like to hear what the plans are for (a) fixing the existing problems, and (b) ensuring that we don't end up in a situation where other architectures are held up because there's nobody who can fix ARM-specific bugs. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: ARM as primary Architecture
On Tue, Jul 09, 2013 at 06:49:10PM +0100, Peter Robinson wrote: > That's correct and you'll find that that's what I've been doing for > 2.5+ years now, but we're talking about Primary here... and in primary > it's everyone's responsibility... That's the point. You don't get to be a primary architecture until you've demonstrated that doing so won't slow down the other architectures, and that requires you to fix all of these problems yourself first. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: ARM as primary Architecture
On Tue, Jul 9, 2013 at 10:50 AM, Matthew Garrett wrote: > llvmpipe has been known to be broken for months, and nobody on the ARM > team appears capable of fixing it. As a result, ARM shipped in F19 > without any out of the box support for running our default desktop. > > This doesn't make it seem like the ARM port currently has sufficient > developer expertise involved, and I'd really like to hear what the plans > are for (a) fixing the existing problems, and (b) ensuring that we don't > end up in a situation where other architectures are held up because > there's nobody who can fix ARM-specific bugs. Does the secureboot situation on arm mean that this primary architecture will eventually be un-bootable for people running a non-redhat signed kernel? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: ARM as primary Architecture
On 07/09/2013 10:53 AM, Gregory Maxwell wrote: Does the secureboot situation on arm mean that this primary architecture will eventually be un-bootable for people running a non-redhat signed kernel? No. We do not support secure boot on ARM in any way. Only devices which ship without secure boot are supported on Fedora. -- Brendan Conoboy / Red Hat, Inc. / b...@redhat.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: ARM as primary Architecture
On Tue, Jul 09, 2013 at 10:53:39AM -0700, Gregory Maxwell wrote: > > Does the secureboot situation on arm mean that this primary architecture > will eventually be un-bootable for people running a non-redhat signed kernel? That's unsupported hardware, in the same way that ipads are. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[perl-Module-Build-Tiny/f18] (4 commits) ...Update to 0.024
Summary of changes: 638d8c6... Update to 0.021 (*) 3532187... Update to 0.022 (*) d060950... Update to 0.023 (*) 3d58630... Update to 0.024 (*) (*) This commit already existed in another branch; no separate mail sent -- 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: Requesting provenpackager help
On Tue, Jul 09, 2013 at 06:48:17PM +0200, Mattia Verga wrote: > I need lazarus in F19 to be rebuilt because the current version was > built against an old Free Pascal Compiler version and doesn't work > with the newer. I have take this task. Best Regards: Jochen Schmitt -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Requesting provenpackager help
On Tue, Jul 09, 2013 at 06:48:17PM +0200, Mattia Verga wrote: > There's nothing to be changed in spec file, just a rebuild is needed > (and to push the update to stable or creating an override in koji). > Is there any provenpackager that can take care of this? I have create an update request and a buildroot override which should expired on 07/20/2013. Best Regards: Jochen Schmitt -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: ARM as primary Architecture
Matthew, We'll be looking into LLVM in due course. There are a few of us capable of fixing the issue (that you were noted as being extremely concerned about on IRC at the time - we will be happy to send you updates on this) but we balance this with other priorities (as well as a desire not to grow a dependency on LLVM more broadly - Fedora relies heavily upon the expertise of RH's tools team, which focuses on GCC almost exclusively precisely to avoid fragmenting the resources that do exist to develop awesome new tooling). Right now, many desktops work just fine, and there is no reason ARM cannot be a a Primary Architecture because of a temporary bug in llvmpipe (or otherwise we can revive this thread for you next time it breaks on the other architecture and see if it should be demoted accordingly?). If there is a rule saying "PA needs GNOME" then this can easily be adjusted to reflect the fact that many are running Fedora on ARM today happily with a variety of other desktop environments. Jon. -- Sent from my iPad On Jul 9, 2013, at 18:57, Matthew Garrett wrote: > llvmpipe has been known to be broken for months, and nobody on the ARM > team appears capable of fixing it. As a result, ARM shipped in F19 > without any out of the box support for running our default desktop. > > This doesn't make it seem like the ARM port currently has sufficient > developer expertise involved, and I'd really like to hear what the plans > are for (a) fixing the existing problems, and (b) ensuring that we don't > end up in a situation where other architectures are held up because > there's nobody who can fix ARM-specific bugs. > > > -- > Matthew Garrett | mj...@srcf.ucam.org > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [Owner-change] Fedora packages ownership change
On Tue, Jul 09, 2013 at 07:01:12PM +0200, Pierre-Yves Chibon wrote: > On Tue, 2013-07-09 at 18:23 +0200, Till Maas wrote: > > On Mon, Jul 08, 2013 at 10:00:04AM +, nob...@fedoraproject.org wrote: > > > Change in ownership over the last 168 hours > > > > How about changing the report time to to last 48-216 hours, then ongoing > > ownership transfers would be recognised as long as they happen within 48 > > hours. > > 168 hours is a week, so ownership transfer should be picked if they > happen within a week. > You would like to have it down to 48h or up to 216h? Actually I was incorrect. I would like it to report orphaned packages in the time frame from 48 hours ago until 216 hours ago (which is again a week), but report packages that have been picked up again in between today to 48 hours ago as transfered from one owner to another. With the current setup, if a package was orphaned shortly before the script ran and claimed shortly afterwards, this will not be shown as a simple transfer but as orphaning and adopting. It irritated me that mstmp was reported as being orphaned, because I noticed that its ownership was transfered recently. Regards Till -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Requesting provenpackager help
On Ter, 2013-07-09 at 20:35 +0200, Jochen Schmitt wrote: > On Tue, Jul 09, 2013 at 06:48:17PM +0200, Mattia Verga wrote: > > > There's nothing to be changed in spec file, just a rebuild is needed > > (and to push the update to stable or creating an override in koji). > > Is there any provenpackager that can take care of this? > > I have create an update request and a buildroot override which should > expired on 07/20/2013. > > Best Regards: > > Jochen Schmitt OK, now we have https://admin.fedoraproject.org/updates/lazarus-1.0.8-2.fc19 Just one detail, when you created the update request, you could have associated with bug #964256 ... Many thanks, -- Sérgio M. B. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [Owner-change] Fedora packages ownership change
On Tue, Jul 09, 2013 at 06:56:03PM +0200, Pierre-Yves Chibon wrote: > On Tue, 2013-07-09 at 18:06 +0200, Till Maas wrote: > > and where the sources of the script can be found. > That would be there: > https://github.com/pypingou/fedora-owner-change Thank you. Have you considered moving this to the fedoraproject infrastructure github project? See: https://github.com/fedora-infra Regards Till -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: ARM as primary Architecture
On Tuesday, July 9, 2013, Jonathan Masters wrote: > Matthew, > > We'll be looking into LLVM in due course. There are a few of us capable of fixing the issue (that you were noted as being extremely concerned about on IRC at the time - we will be happy to send you updates on this) but we balance this with other priorities (as well as a desire not to grow a dependency on LLVM more broadly - Fedora relies heavily upon the expertise of RH's tools team, which focuses on GCC almost exclusively precisely to avoid fragmenting the resources that do exist to develop awesome new tooling). Right now, many desktops work just fine, and there is no reason ARM cannot be a a Primary Architecture because of a temporary bug in llvmpipe (or otherwise we can revive this thread for you next time it breaks on the other architecture and see if it should be demoted accordingly?). If there is a rule saying "PA needs GNOME" then this can easily be adjusted to reflect the fact that many are running Fedora on ARM today happily with a variety of other desktop environments. > It is not only that one desktop does not work but pretty much everything that uses GL ... Which is not acceptable in 2013 IMO ... And this has nothing to do with GCC vs llvm either ... -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: ARM as primary Architecture
On Tue, Jul 09, 2013 at 06:50:07PM +0100, Matthew Garrett wrote: > llvmpipe has been known to be broken for months, and nobody on the ARM > team appears capable of fixing it. As a result, ARM shipped in F19 > without any out of the box support for running our default desktop. > > This doesn't make it seem like the ARM port currently has sufficient > developer expertise involved, and I'd really like to hear what the plans > are for (a) fixing the existing problems, and (b) ensuring that we don't > end up in a situation where other architectures are held up because > there's nobody who can fix ARM-specific bugs. I'm also concerned that stack protector does not workyet at all. Even if the desktop was useable, how would we tell people that it's okay to run e.g. firefox with a straight face? It's not as bad as if, say, selinux didn't work, but it's a significant concern. -- Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: ARM as primary Architecture
On Tue, Jul 09, 2013 at 03:00:05PM +0200, Jaroslav Reznik wrote: > = Proposed System Wide Change: ARM as primary Architecture = > https://fedoraproject.org/wiki/Changes/ARM_as_Primary > > Change owner(s): Dennis Gilmore , Peter Robinson > > > Make ARM a primary architecture. Add armv7hl to the i686 and x86_64 as arches > that we build and support. This will mean that all packages supported by the > ARM architecture must build for ARM to be released. With the release of > Fedora > 19 we have deprecated support for software floating support (ARMv5tel sfp) so > the only proposed addition to primary architectures is currently ARMv7 > hardware floating point 32 bit support (ARMv7 hfp 32bit). Which hardware is supported by ARMv7 hfp 32bit builds? Will there be test instances for maintainers as described here: https://fedoraproject.org/wiki/Test_Machine_Resources_For_Package_Maintainers f17-arm-test.scrye.com is currently not reachable for me. Regards Till -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: ARM as primary Architecture
On Tue, Jul 9, 2013 at 10:11 PM, Till Maas wrote: > On Tue, Jul 09, 2013 at 03:00:05PM +0200, Jaroslav Reznik wrote: >> = Proposed System Wide Change: ARM as primary Architecture = >> https://fedoraproject.org/wiki/Changes/ARM_as_Primary >> >> Change owner(s): Dennis Gilmore , Peter Robinson >> >> >> Make ARM a primary architecture. Add armv7hl to the i686 and x86_64 as arches >> that we build and support. This will mean that all packages supported by the >> ARM architecture must build for ARM to be released. With the release of >> Fedora >> 19 we have deprecated support for software floating support (ARMv5tel sfp) so >> the only proposed addition to primary architectures is currently ARMv7 >> hardware floating point 32 bit support (ARMv7 hfp 32bit). > > Which hardware is supported by ARMv7 hfp 32bit builds? Will there be http://fedoraproject.org/wiki/Architectures/ARM The list is expanding regularly and there's a lot of other hardware currently supported by remix primarily because the complete kernel support isn't upstream. > test instances for maintainers as described here: > https://fedoraproject.org/wiki/Test_Machine_Resources_For_Package_Maintainers I've never seen the above before. There's instances available to QA https://fedoraproject.org/wiki/Architectures/ARM/qa-machines > f17-arm-test.scrye.com is currently not reachable for me. Didn't know it existed so I'm not sure who maintains it. Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: ARM as primary Architecture
On Tue, 2013-07-09 at 14:54 -0400, Jonathan Masters wrote: > We'll be looking into LLVM in due course. There are a few of us > capable of fixing the issue (that you were noted as being extremely > concerned about on IRC at the time - we will be happy to send you > updates on this) but we balance this with other priorities (as well as > a desire not to grow a dependency on LLVM more broadly Functional llvmpipe isn't a new dependency. Every primary arch has had it working since F17. Two of the secondaries do too in F19. I appreciate not wanting to depend more on llvm - believe me I really, really, really, do - but I don't think you get to use that as an out here. > - Fedora relies heavily upon the expertise of RH's tools team, which > focuses on GCC almost exclusively precisely to avoid fragmenting the > resources that do exist to develop awesome new tooling). Sure, but arm also builds without -fstack-protector because it's plainly unimplemented, which is a fairly major security regression compared to every other architecture. The conclusion one might draw is that there's no toolchain attention being paid to arm at all. Which doesn't inspire in me much confidence. - ajax -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: ARM as primary Architecture
On 2013-07-09 10:53, Gregory Maxwell wrote: On Tue, Jul 9, 2013 at 10:50 AM, Matthew Garrett wrote: llvmpipe has been known to be broken for months, and nobody on the ARM team appears capable of fixing it. As a result, ARM shipped in F19 without any out of the box support for running our default desktop. This doesn't make it seem like the ARM port currently has sufficient developer expertise involved, and I'd really like to hear what the plans are for (a) fixing the existing problems, and (b) ensuring that we don't end up in a situation where other architectures are held up because there's nobody who can fix ARM-specific bugs. Does the secureboot situation on arm mean that this primary architecture will eventually be un-bootable for people running a non-redhat signed kernel? I think you're mistaking "the secure boot situation on *Microsoft* ARM" for "the secure boot situation on ARM". ARM devices that want to come with an OEM copy of Windows RT pre-installed have to do certain things with Secure Boot which effectively prevent anyone else from booting on them. Okay. So, we don't support such devices. Microsoft cannot magically apply their OEM licensing requirements to Every ARM Device Ever, including all the ones that don't run Windows RT. Which is like 97+% of ARM devices, given the Windows RT sales figures so far. Various other popular consumer ARM devices use other techniques - *not* UEFI Secure Boot - for locking out alternative OSes, so Fedora isn't going to work on those either, unless they're hacked. Too bad. As bconoboy says, such things simply fall in the 'unsupported hardware' box. When reading media articles about SB, bear in mind they're usually wildly inaccurate. For the straight dope, apply to mjg59, pjones, or if neither of them is available, me (but remember I'm just the monkey). -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: ARM as primary Architecture
On 2013-07-09 6:00, Jaroslav Reznik wrote: = Proposed System Wide Change: ARM as primary Architecture = https://fedoraproject.org/wiki/Changes/ARM_as_Primary The kernel is now a multi platform unified ARMv7 kernel supporting a number of SoCs with support expanding with each new upstream release. We build a base and LPAE variant similar to i686. There is an ARM specific (ARMv7 and aarch64) kernel maintainer working in collaboration with the Fedora kernel team. The releases are composed using the exact same tooling as used for the primary architectures. Disk images for development boards are generated by appliance- creator and the kickstarts live in spin-kickstarts, they take a similar format as the livecds on primary but are shipped as an OEM disk image, and like primary initial-setup is used to do final user configuration. Like primary pungi is used to generate an install tree, PXE install trees are created but current bootloaders don't support isofs so ISO images aren't currently created. So, this raises a few questions: with ARM as a primary arch, exactly what set of release images would we be supporting? Would we expect to test each device-specific image at each release point and verify each one of them was correct? Or would we just test a subset and 'trust' that the others worked? Do 'we' as a project have access to all the necessary hardware for testing each of the images? (Personally, I have an XO 1.75 and a Trimslice lying around here somewhere; I don't know what else anyone else has squirrelled away). Someone later in the thread asked whether the 'ARM team' would be on the hook for QAing the entire kaboodle. Technically with ARM as a primary arch it would be QA's responsibility to ensure that whatever images we considered part of the 'primary release' were of releasable quality, but we are not miracle workers, and we cannot test what we don't have: so we'd either need to buy a bunch of test devices or rely on people who already have an interest in using ARM and some ARM devices - so, the ARM team... - to act under the auspices of the 'QA team'. I've had an entry on my todo list _forever_ to complete the 'deliverables SOP' I started several releases ago: https://fedoraproject.org/wiki/User:Adamwill/Draft_releng_SOP_deliverables (I don't really like the current layout, I was planning on revising it) The addition of a new arch with quite a pile of 'supported images' would certainly raise the priority of having such a thing. (We're already hitting a problem with our *current* primary arches in this area, though, in that the status of the multi-live, multi-arch and cloud/appliance images is rather unclear). -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: ARM as primary Architecture
Adam Williamson (awill...@redhat.com) said: > I've had an entry on my todo list _forever_ to complete the > 'deliverables SOP' I started several releases ago: > > https://fedoraproject.org/wiki/User:Adamwill/Draft_releng_SOP_deliverables > > (I don't really like the current layout, I was planning on revising it) > > The addition of a new arch with quite a pile of 'supported images' > would certainly raise the priority of having such a thing. (We're > already hitting a problem with our *current* primary arches in this > area, though, in that the status of the multi-live, multi-arch and > cloud/appliance images is rather unclear). Plus, in relation to this - the llvmpipe issue brings up that one of the 'release blocking desktops' *does not work*. This would, by definition, block the release unless we intend to have different criteria for ARM as a primary arch. Outside of that, how might we expect release criteria to change for ARM, given the different deliverables that are planned? Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: ARM as primary Architecture
On Tue, Jul 9, 2013 at 7:22 PM, Adam Williamson wrote: > When reading media articles about SB, bear in mind they're usually wildly > inaccurate. For the straight dope, apply to mjg59, pjones, or if neither of > them is available, me (but remember I'm just the monkey). You can ask me as well. I wrote quite a few of the SB patches we're carrying in the kernel. Whether that makes me more than a monkey, I have no idea. josh -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: How to remove auto generated python dependency?
On Tue, Jul 9, 2013 at 12:10 PM, Toshio Kuratomi wrote:
> On Tue, Jul 09, 2013 at 04:37:40PM +0100, Daniel P. Berrange wrote:
>> On Tue, Jul 09, 2013 at 05:26:19PM +0200, Denys Vlasenko wrote:
>> > Hi,
>> >
>> > A package I maintain (mc) has two rarely-used
>> > python scripts.
>> >
>> > Since they have #!/usr/bin/python header, build machinery
>> > automatically adds python dependency.
>> >
>> > But I don't want this to happen - the program is very much
>> > usable without python too. Requiring python pulls in a top
>> > of other stuff which isn't needed.
>>
>> Are those scripts installed into /usr/bin ? If so then, IMHO,
>> removing the python dependency is not appropriate, regardless
>> of whether the scripts are used frequently or not. Splitting
>> them out into a sub-RPM might be a more suitable approach.
>>
> -- If this is a Fedora package, then a subpackage is definitely the
> way to go. Filtering out a dependency that is actually present would be
> introducing a bug.
>
> -Toshio
If you wanted to be a complete weasel, you could use "#!/usr/bin/env
python". If the scripts are samples or add-on scripts, not normally
deployed, such as the suite of server-side post-comit nad pre-common
tools for Subversion, you might dump them in
/usr/share/doc/[package]-%{version}/scripts, and turn off the execute
bit.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Scratch Builds
Hi folks, Just in case, let's say we have the package foo-1.0 if I make a scratch build of package foo-1.1, that doesn't count at all, isn't it? I mean can I send an update foo-.1.1 completely different of the foo-1.1 sent as a scratch build, can't I? Thanks in advance -- -- Sergio Belkin http://www.sergiobelkin.com Watch More TV http://sebelk.blogspot.com LPIC-2 Certified - http://www.lpi.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: ARM as primary Architecture
On Tue, Jul 09, 2013 at 02:54:53PM -0400, Jonathan Masters wrote: > Matthew Garrett wrote: > > This doesn't make it seem like the ARM port currently has sufficient > > developer expertise involved, and I'd really like to hear what the plans > > are for (a) fixing the existing problems, and (b) ensuring that we don't > > end up in a situation where other architectures are held up because > > there's nobody who can fix ARM-specific bugs. > > We'll be looking into LLVM in due course. There are a few of us > capable of fixing the issue (that you were noted as being extremely > concerned about on IRC at the time - we will be happy to send you > updates on this) but we balance this with other priorities (as well as > a desire not to grow a dependency on LLVM more broadly - Fedora relies > heavily upon the expertise of RH's tools team, which focuses on GCC > almost exclusively precisely to avoid fragmenting the resources that > do exist to develop awesome new tooling). Right now, many desktops > work just fine, and there is no reason ARM cannot be a a Primary > Architecture because of a temporary bug in llvmpipe (or otherwise we > can revive this thread for you next time it breaks on the other > architecture and see if it should be demoted accordingly?). If there > is a rule saying "PA needs GNOME" then this can easily be adjusted to > reflect the fact that many are running Fedora on ARM today happily > with a variety of other desktop environments. There's a few of you capable of fixing the issue, but there were enough other things to fix that you didn't have time? That doesn't answer my question. What are the plans to ensure that there's enough ARM expertise in Fedora to ensure that ARM-specific bugs in critical infrastructure packages (like LLVM) don't end up as release blockers? -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Scratch Builds
On Tue, 2013-07-09 at 23:42 -0300, Sergio Belkin wrote: > Just in case, let's say we have the package foo-1.0 if I make a > scratch build of package foo-1.1, that doesn't count at all, isn't > it? > I mean can I send an update foo-.1.1 completely different of the > foo-1.1 sent as a scratch build, can't I? Right, scratch builds are exactly what they sound like -- they're done on the Koji infrastructure but the build is basically ignored. -Chris -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: ARM as primary Architecture
On 2013-07-09 17:36, Bill Nottingham wrote: Adam Williamson (awill...@redhat.com) said: I've had an entry on my todo list _forever_ to complete the 'deliverables SOP' I started several releases ago: https://fedoraproject.org/wiki/User:Adamwill/Draft_releng_SOP_deliverables (I don't really like the current layout, I was planning on revising it) The addition of a new arch with quite a pile of 'supported images' would certainly raise the priority of having such a thing. (We're already hitting a problem with our *current* primary arches in this area, though, in that the status of the multi-live, multi-arch and cloud/appliance images is rather unclear). Plus, in relation to this - the llvmpipe issue brings up that one of the 'release blocking desktops' *does not work*. This would, by definition, block the release unless we intend to have different criteria for ARM as a primary arch. Outside of that, how might we expect release criteria to change for ARM, given the different deliverables that are planned? I've looked at that several times, and I don't really think the criteria need to change much at all. The way they're currently worded covers ARM pretty well, I think. We revised them quite extensively for F19 and I tried to keep ARM in mind in the wording used there. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Scratch Builds
On Tue, Jul 09, 2013 at 11:42:48PM -0300, Sergio Belkin wrote: > Just in case, let's say we have the package foo-1.0 if I make a scratch > build of package foo-1.1, that doesn't count at all, isn't it? > I mean can I send an update foo-.1.1 completely different of the foo-1.1 > sent as a scratch build, can't I? Right, scratch builds don't count. But, I encourage you to increment release number anyway. There are plenty of numbers, so you won't run out, and it's easy to get confused about versions and changes -- just always increment, and that won't happen. -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: excellent work!
On Wed, Jul 3, 2013 at 2:13 PM, Neal Becker wrote: > Just want to say I updated 2 machines using fedup, and everything seems to > have > gone perfectly. > > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel I second the above. Thus far I upgraded >20 machines ranging from high-end Xeon servers down to atom embedded systems and for the first time since, well, more-or-less ever (and I've been using Fedora/RedHat since RHL 6.1..), *all* the machines successfully went from Fedora 18 to Fedora 19 with zero manual intervention. Huge (!) congrats to the fedup team. - Gilboa -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: excellent work!
On 2013-07-09 22:35, Gilboa Davara wrote: On Wed, Jul 3, 2013 at 2:13 PM, Neal Becker wrote: Just want to say I updated 2 machines using fedup, and everything seems to have gone perfectly. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel I second the above. Thus far I upgraded >20 machines ranging from high-end Xeon servers down to atom embedded systems and for the first time since, well, more-or-less ever (and I've been using Fedora/RedHat since RHL 6.1..), *all* the machines successfully went from Fedora 18 to Fedora 19 with zero manual intervention. Huge (!) congrats to the fedup team. That would be mostly Will, wearing a series of silly moustaches. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
