Fatal flaw in the udev paradigm?
I have run into an issue which seems to call into question the udev paradigm for USB devices. In my case it has ramifications in ModemManager and gpsd packages, but I see it as a fundamental problem with udev which is in all current versions of Fedora. My USB GPS is a BU-353 which uses a pl2303 USB-Serial Controller (idVendor=067b, idProduct=2303). However, bugzilla report 878737 indicates this same interface chip is used on other devices such as RS232-USB adapters. If the device is a GPS you do not want ModemManager run on it (bugzilla 1023234) but you do want gpsctl to tell gpsd about it when it is plugged in. If it is a RS232 adapter the opposite is true (bugzilla 878737). Note that it is reported that the DU-353 can be bricked if the wrong thing is written to it. After looking at the lsusb -v output for my BU-353 and the output for RS232 devices reported on the net, I do not see any way to distinguish between the two different types of devices that udev could use to tell them apart. Unless I am missing something this seems like a fatal flaw in the udev paradigm. Regards Roy Rankin -- 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: Fatal flaw in the udev paradigm?
Le Jeu 31 octobre 2013 07:03, rran...@ihug.com.au a écrit : I have run into an issue which seems to call into question the udev paradigm for USB devices. It's not a fatal flaw it's broken hardware (and autodetection broken by device manufacturers not bothering to replace OEM id with their own is nothing new or USB-specific) Regards, -- Nicolas Mailhot -- 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: $HOME/.local/bin in $PATH
Hi, Anyway what makes xdg specs a total wreakage is the way they've replaced dotfiles with other dotfiles only to create prettyfied localized symlinks à la windows (a bad case of over-engineering and aping another os without understanding drawbacks) Had they specified a ~/xdg/ root, with a static directory hierarchy under it, no hidden files, no you-need-to-run-a-command-to-known-where-stuff is, no magic env variables, it would have been a sane environment for apps, scripts, selinux, apparmor, etc And they could even have auto-replaced the standard static names with localized labels in GUI file browsers with no functionality loss at all. As it is we got a frankeinspec, a little better than what existed before, and completely hostile to anyone trying to actually use it to deploy user-specific bits Regards, -- Nicolas Mailhot -- 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: $HOME/.local/bin in $PATH
On Thu, Oct 31, 2013 at 10:01 AM, Nicolas Mailhot nicolas.mail...@laposte.net wrote: Hi, Anyway what makes xdg specs a total wreakage is the way they've replaced dotfiles with other dotfiles only to create prettyfied localized symlinks That's incorrect. The prettyfied localized symlinks are neither symlinks nor are they hidden. à la windows (a bad case of over-engineering and aping another os without understanding drawbacks) Seems like you do not really understand what you are criticizing. Had they specified a ~/xdg/ root, with a static directory hierarchy under it, no hidden files, no you-need-to-run-a-command-to-known-where-stuff is, no magic env variables, it would have been a sane environment for apps, scripts, selinux, apparmor, etc The hidden directories replaced the mess that we had before where each app stores stuff in random (hidden) directories. Having a standardized directory structure is actually a sane environment. As for why they are hidden (and always have been) is because you do not want to bother the user with them most of the time. -- 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: $HOME/.local/bin in $PATH
On Thu, 2013-10-31 at 10:12 +0100, drago01 wrote: As for why they are hidden (and always have been) is because you do not want to bother the user with them most of the time. That being said, they could have not started by a ., but still be hidden by the GUI file managers like Nautilus (for example by listing them in a .hidden file). That could have pleased those who don't like hidden files, while at the same time not bothering users who don't want to see them. In any case, it's not worth changing everything now. I for one am happy that things are more and more moving to the .config and .local folders. :) -- Mathieu -- 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: Fatal flaw in the udev paradigm?
On 31/10/13 08:42, Nicolas Mailhot wrote: Le Jeu 31 octobre 2013 07:03, rran...@ihug.com.au a écrit : I have run into an issue which seems to call into question the udev paradigm for USB devices. It's not a fatal flaw it's broken hardware (and autodetection broken by device manufacturers not bothering to replace OEM id with their own is nothing new or USB-specific) It's also an issue that the NetworkManager/ModemManager developers are well aware of - a recent thread on the subject starts here: https://mail.gnome.org/archives/networkmanager-list/2013-October/msg00037.html with details of how ModemManager deals with the problem here: https://mail.gnome.org/archives/networkmanager-list/2013-October/msg00046.html so in short this device should be added to the greylist if it isn't there already, and then it will only be probed when such a probe is explicitly requested. Note that F19 is using MM 0.6 so doesn't have the greylist. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ -- 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: Fatal flaw in the udev paradigm?
On 31/10/13 09:56, Tom Hughes wrote: so in short this device should be added to the greylist if it isn't there already, and then it will only be probed when such a probe is explicitly requested. and the PL2303 is indeed in the greylist: http://cgit.freedesktop.org/ModemManager/ModemManager/tree/src/77-mm-usb-serial-adapters-greylist.rules#n20 Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
openssl multilib broken
currently on a x86_64 system distro-sync to F19 is broken i saw the same in F18 with updates-testing enabled on a machine with i686 packages some days ago and download the openssl packages for both archs from koji and doing a yum localupdate worked fine Error: Package: 1:openssl-1.0.1e-29.fc18.i686 (@/openssl-1.0.1e-29.fc18.i686/18) Requires: openssl-libs(x86-32) = 1:1.0.1e-29.fc18 Removing: 1:openssl-libs-1.0.1e-29.fc18.i686 (@/openssl-libs-1.0.1e-29.fc18.i686/18) openssl-libs(x86-32) = 1:1.0.1e-29.fc18 Updated By: 1:openssl-libs-1.0.1e-30.fc19.i686 (updates) openssl-libs(x86-32) = 1:1.0.1e-30.fc19 Available: 1:openssl-libs-1.0.1e-4.fc19.i686 (fedora) openssl-libs(x86-32) = 1:1.0.1e-4.fc19 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
[perl-Authen-Radius] Created tag perl-Authen-Radius-0.23-1.fc21
The lightweight tag 'perl-Authen-Radius-0.23-1.fc21' was created pointing to: 131534e... Update to 0.23 -- 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
[Test-Announce] Fedora 20 Beta Go/No-Go Meeting #2, Thursday, October 31 @ 17:00 UTC
Join us on irc.freenode.net in #fedora-meeting-2 for this important meeting, wherein we shall determine the readiness of the Fedora 20 Beta. This is the second attempt to release Fedora 20 Beta. Currently, we're waiting for possible RC1 compose. Thursday, October 31, 2013 17:00 UTC (1 PM EDT, 10 AM PDT, 18:00 CET) Before each public release Development, QA and Release Engineering meet to determine if the release criteria are met for a particular release. This meeting is called the Go/No-Go Meeting. Verifying that the Release criteria are met is the responsibility of the QA Team. For more details about this meeting see: https://fedoraproject.org/wiki/Go_No_Go_Meeting In the meantime, keep an eye on the Fedora 20 Beta Blocker list: http://qa.fedoraproject.org/blockerbugs/milestone/20/beta/buglist PS: sorry for late reminder but I'm sick... Jaroslav ___ test-announce mailing list test-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/test-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
Is Gnome Software ready for primetime ?
I have tested gnome-software to see the current state, compaired to gpk in F19, there is a lot stuff there cant be done. 1. You cant install backgrounds / icons 2. Not all application found in the menu, can be found under installed, you can search for them and find them, but cant remove them (ex. Document viewer) 3. if you search for 'icons' you get at lot of wrong positives, where there is no visible relation to icons in the text shown 4. Description is missing from almost every application. This is just a few of the issues i have made bug reports on, but the main question is gnome-software ready for the one an only software manager for the primary desktop for Fedora ? I think the current state will make Fedora look limitted for new Fedora users. PS. Please dont turn this into a flame war for/against gnome :) Tim -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Taskbot: TAP vs Subunit
Tim (and of course the rest of the gang ;)), During our chat with Tim, we agreed that we'd really like to use some standardized 'output format' for the tests in Taskbot, to be a bit more programming-language/results-store-implementation agnostic. We knew about two options - TAP http://testanything.org/wiki/index.php/Main_Page and Subunit https://pypi.python.org/pypi/python-subunit. = Subunit = At least in Python is quite tightly coupled with unittest, both ideologically and practically. I was unable to find a way to just produce a Subunit stream without the need of actually running a testsuite. The format is (basically) just plain PASS/FAIL/INFO/..., and there is possibility to add some 'details'results. It should also be possible to add an attachment to the end of the stream, but no result-specific data can be added (IMO). Also Subunit is now in the process of transition to new implementation, which now should fix some issues with concurrency, add more result-states, etc., but will be binary, so human readability would quite suffer. I do not really feel that this is a good match for our needs (at least without any significant hacking) = TAP = TAP is not unittest-specific, and is human-readable plaintext format. It also has just PASS/FAIL logic, but there is a possibility to add YAML 'metadata' to any result (since TAP v. 13). The real issue with TAP is Python support. There is a TAP-consumer library created as an example for PyParsing http://pyparsing.wikispaces.com/file/detail/TAP.py, but it does not support the v13 protocol, and is quite useless as such. TAP-producer library for Python https://github.com/rjbs/pytap is also using the old version (i.e. no YAML extensions), and seems to be dead (2 years since last update). It is also quite badly written. = Result = Although neither choice is ideal, I feel that TAP would be the better choice, even though it would mean implementing our own producer/parser. Also the TAP is really simplistic format, so creating a TAP output should be quite easy even in any programming language. It is possible that I somehow utterly misunderstood the Subunit concept, so it might be useful to contact some QAs currently using it (I thing Tim mentioned something about OpenStack?), or contact the developer directly. J. ___ qa-devel mailing list qa-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/qa-devel
Broken dependencies: perl-MIME-Lite-HTML
perl-MIME-Lite-HTML has broken dependencies in the F-20 tree: On x86_64: perl-MIME-Lite-HTML-1.24-4.fc18.noarch requires perl(:MODULE_COMPAT_5.16.0) On i386: perl-MIME-Lite-HTML-1.24-4.fc18.noarch requires perl(:MODULE_COMPAT_5.16.0) On armhfp: perl-MIME-Lite-HTML-1.24-4.fc18.noarch requires perl(:MODULE_COMPAT_5.16.0) Please resolve this as soon as possible. -- 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
Broken dependencies: perl-Padre
perl-Padre has broken dependencies in the F-20 tree: On x86_64: perl-Padre-0.90-6.fc18.noarch requires perl(:MODULE_COMPAT_5.16.0) On i386: perl-Padre-0.90-6.fc18.noarch requires perl(:MODULE_COMPAT_5.16.0) On armhfp: perl-Padre-0.90-6.fc18.noarch requires perl(:MODULE_COMPAT_5.16.0) Please resolve this as soon as possible. -- 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
Broken dependencies: perl-BerkeleyDB
perl-BerkeleyDB has broken dependencies in the F-20 tree: On x86_64: perl-BerkeleyDB-0.53-1.fc20.x86_64 requires libdb = 0:5.3.21 On i386: perl-BerkeleyDB-0.53-1.fc20.i686 requires libdb = 0:5.3.21 On armhfp: perl-BerkeleyDB-0.53-1.fc20.armv7hl requires libdb = 0:5.3.21 Please resolve this as soon as possible. -- 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
Broken dependencies: perl-PDL
perl-PDL has broken dependencies in the F-20 tree: On x86_64: perl-PDL-2.4.10-6.fc19.x86_64 requires perl(:MODULE_COMPAT_5.16.2) perl-PDL-2.4.10-6.fc19.x86_64 requires libgd.so.2()(64bit) On i386: perl-PDL-2.4.10-6.fc19.i686 requires perl(:MODULE_COMPAT_5.16.2) perl-PDL-2.4.10-6.fc19.i686 requires libgd.so.2 Please resolve this as soon as possible. -- 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
Broken dependencies: perl-Language-Expr
perl-Language-Expr has broken dependencies in the F-20 tree: On x86_64: perl-Language-Expr-0.19-4.fc19.noarch requires perl(:MODULE_COMPAT_5.16.2) On i386: perl-Language-Expr-0.19-4.fc19.noarch requires perl(:MODULE_COMPAT_5.16.2) On armhfp: perl-Language-Expr-0.19-4.fc19.noarch requires perl(:MODULE_COMPAT_5.16.2) Please resolve this as soon as possible. -- 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
Broken dependencies: slic3r
slic3r has broken dependencies in the F-20 tree: On x86_64: slic3r-0.9.10b-2.fc20.noarch requires perl(:MODULE_COMPAT_5.16.3) On i386: slic3r-0.9.10b-2.fc20.noarch requires perl(:MODULE_COMPAT_5.16.3) On armhfp: slic3r-0.9.10b-2.fc20.noarch requires perl(:MODULE_COMPAT_5.16.3) Please resolve this as soon as possible. -- 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: Is Gnome Software ready for primetime ?
On Thu, 2013-10-31 at 12:13 +0100, Tim Lauridsen wrote: I have tested gnome-software to see the current state, compaired to gpk in F19, there is a lot stuff there cant be done. 1. You cant install backgrounds / icons It is an application installer, first and foremost. Installing backgrounds/icons/themes is not a priority. That being said, 3.11 can install fonts and codecs. 2. Not all application found in the menu, can be found under installed, you can search for them and find them, but cant remove them (ex. Document viewer) What menu ? And what application ? We have a notion of 'core app' - for things that 'come with the OS'. We don't allow to uninstall those. 3. if you search for 'icons' you get at lot of wrong positives, where there is no visible relation to icons in the text shown Search looks at keywords from desktop files in addition to descriptions and names. Would be good to see some concrete examples of the false positives you get. I only get gnome-tweak-tool and some icon-related font. 4. Description is missing from almost every application. Richard has pushed very hard for getting descriptions upstream - you may have seen his repeated posts on this topic. And we have made quite a bit of progress. But getting every application equipped with a good description, screenshots, and other metadata will take some time, and some help from the packagers and maintainers of those applications. I think the current state will make Fedora look limitted for new Fedora users. Compared to Ubuntu, certainly. But compared to gpk-application F19, I don't think so. -- 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: Fatal flaw in the udev paradigm?
On Thu, Oct 31, 2013 at 11:52:18 +0100, Florian Weimer fwei...@redhat.com wrote: I might be missing something, but to me that seems just life with a generic transport that doesn't have built-in identification of connected devices. This applies to RS232 (your case), but also to the (classic) parallel port and even to Ethernet. In such cases, plug-and-play won't work, but that doesn't seem like a big deal to me. PCI devices can have the same problem. To use my TDM2400 I need to blacklist netjet to prevent netjet's driver from trying to manage the device. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
F-20 Branched report: 20131031 changes
Compose started at Thu Oct 31 09:15:03 UTC 2013 Broken deps for armhfp -- [blueman] blueman-1.23-7.fc20.armv7hl requires obex-data-server = 0:0.4.3 blueman-1.23-7.fc20.armv7hl requires gvfs-obexftp [bwm-ng] bwm-ng-0.6-11.1.fc20.armv7hl requires libstatgrab.so.9 [cloud-init] cloud-init-0.7.2-7.fc20.noarch requires dmidecode [cobbler] cobbler-2.4.0-2.fc20.noarch requires syslinux [condor-wallaby] condor-wallaby-client-5.0.3-4.fc20.noarch requires python-qmf = 0:0.9.1073306 [fts] fts-server-3.1.1-1.fc20.armv7hl requires libactivemq-cpp.so.14 [glpi] glpi-0.84.2-1.fc20.noarch requires php-ZendFramework2-Version glpi-0.84.2-1.fc20.noarch requires php-ZendFramework2-Stdlib glpi-0.84.2-1.fc20.noarch requires php-ZendFramework2-ServiceManager glpi-0.84.2-1.fc20.noarch requires php-ZendFramework2-Loader glpi-0.84.2-1.fc20.noarch requires php-ZendFramework2-I18n glpi-0.84.2-1.fc20.noarch requires php-ZendFramework2-Cache-apc glpi-0.84.2-1.fc20.noarch requires php-ZendFramework2-Cache [gnome-do-plugins] gnome-do-plugins-thunderbird-0.8.4-14.fc20.armv7hl requires thunderbird [gofer] ruby-gofer-0.75-4.fc20.noarch requires rubygem(qpid) = 0:0.16.0 [gradle] gradle-1.0-18.fc20.noarch requires plexus-container-default [grass] grass-6.4.3-2.fc20.armv7hl requires libgeos-3.3.8.so grass-libs-6.4.3-2.fc20.armv7hl requires libgeos-3.3.8.so [gtkd] gtkd-geany-tags-2.0.0-29.20120815git9ae9181.fc18.noarch requires gtkd = 0:2.0.0-29.20120815git9ae9181.fc18 [kawa] 1:kawa-1.11-5.fc19.armv7hl requires servlet25 [koji] koji-vm-1.8.0-2.fc20.noarch requires python-virtinst [kyua-cli] kyua-cli-0.5-3.fc19.armv7hl requires liblutok.so.0 kyua-cli-tests-0.5-3.fc19.armv7hl requires liblutok.so.0 [monotone] monotone-1.0-11.fc19.armv7hl requires libbotan-1.8.2.so perl-Monotone-1.0-11.fc19.armv7hl requires perl(:MODULE_COMPAT_5.16.2) [mozilla-firetray] mozilla-firetray-thunderbird-0.3.6-0.5.143svn.fc18.1.armv7hl requires thunderbird = 0:11 [msp430-libc] msp430-libc-20120224-2.fc19.noarch requires msp430-gcc = 0:4.6.3 [nifti2dicom] nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtksys.so.5.10 nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtkWidgets.so.5.10 nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtkVolumeRendering.so.5.10 nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtkViews.so.5.10 nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtkTextAnalysis.so.5.10 nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtkRendering.so.5.10 nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtkParallel.so.5.10 nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtkInfovis.so.5.10 nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtkImaging.so.5.10 nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtkIO.so.5.10 nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtkHybrid.so.5.10 nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtkGraphics.so.5.10 nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtkGeovis.so.5.10 nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtkGenericFiltering.so.5.10 nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtkFiltering.so.5.10 nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtkCommon.so.5.10 nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtkCharts.so.5.10 nifti2dicom-0.4.6-3.fc20.armv7hl requires libQVTK.so.5.10 [nocpulse-common] nocpulse-common-2.2.7-2.fc20.noarch requires perl(RHN::DBI) [openbox] gdm-control-3.5.2-2.fc20.armv7hl requires gnome-panel gnome-panel-control-3.5.2-2.fc20.armv7hl requires gnome-panel [openpts] openpts-0.2.6-7.fc20.armv7hl requires tboot [osm2pgsql] osm2pgsql-0.82.0-1.fc20.armv7hl requires libgeos-3.3.8.so [oyranos] oyranos-libs-0.4.0-7.fc19.armv7hl requires libraw.so.5 [perl-BerkeleyDB] perl-BerkeleyDB-0.53-1.fc20.armv7hl requires libdb = 0:5.3.21 [perl-Language-Expr] perl-Language-Expr-0.19-4.fc19.noarch requires perl(:MODULE_COMPAT_5.16.2) [perl-MIME-Lite-HTML] perl-MIME-Lite-HTML-1.24-4.fc18.noarch requires perl(:MODULE_COMPAT_5.16.0) [perl-Padre] perl-Padre-0.90-6.fc18.noarch requires perl(:MODULE_COMPAT_5.16.0) [pure] pure-doc-0.57-4.fc20.noarch requires pure = 0:0.57-4.fc20 [python-tag] python-tag-2013.1-1.fc20.armv7hl requires libboost_python.so.1.53.0 [rootplot] rootplot-2.2.1-7.fc19.noarch requires root-python [ruby-spqr] ruby-spqr-0.3.6-7.fc20.noarch requires ruby-qpid-qmf [rubygem-audited-activerecord] rubygem-audited-activerecord-3.0.0-3.fc19.noarch requires rubygem(activerecord) 0:4 [rubygem-fog] rubygem-fog-1.11.1-1.fc20.noarch requires rubygem(nokogiri) 0:1.6 [scala]
Re: openssl multilib broken
On Thu, 31 Oct 2013 11:12:41 +0100, Reindl Harald wrote: currently on a x86_64 system distro-sync to F19 is broken i saw the same in F18 with updates-testing enabled on a machine with i686 packages some days ago and download the openssl packages for both archs from koji and doing a yum localupdate worked fine Error: Package: 1:openssl-1.0.1e-29.fc18.i686 (@/openssl-1.0.1e-29.fc18.i686/18) Where did you find openssl.i686 in the x86_64 repos? Did you download it from koji? The repo id in brackets is suspicious. Here is only openssl.x86_64 release -30.fc18: http://dl.fedoraproject.org/pub/fedora/linux/updates/testing/18/x86_64/ Here is only openssl.x86_64 release -28.fc18: http://dl.fedoraproject.org/pub/fedora/linux/updates/18/x86_64/ It seems to me the openssl base package is not pulled in by the multilib composer (because openssl-devel only requires openssl-libs). -- 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: openssl multilib broken
Am 31.10.2013 13:49, schrieb Michael Schwendt: On Thu, 31 Oct 2013 11:12:41 +0100, Reindl Harald wrote: currently on a x86_64 system distro-sync to F19 is broken i saw the same in F18 with updates-testing enabled on a machine with i686 packages some days ago and download the openssl packages for both archs from koji and doing a yum localupdate worked fine Error: Package: 1:openssl-1.0.1e-29.fc18.i686 (@/openssl-1.0.1e-29.fc18.i686/18) Where did you find openssl.i686 in the x86_64 repos? Did you download it from koji? The repo id in brackets is suspicious. Here is only openssl.x86_64 release -30.fc18: http://dl.fedoraproject.org/pub/fedora/linux/updates/testing/18/x86_64/ Here is only openssl.x86_64 release -28.fc18: http://dl.fedoraproject.org/pub/fedora/linux/updates/18/x86_64/ yum --enablerepo=updates-testing update openssl\* did not work because different versions for x86_64 and i686 and so i downloaded it from koji It seems to me the openssl base package is not pulled in by the multilib composer (because openssl-devel only requires openssl-libs) but skype or whatever pulls dependencies 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: Is Gnome Software ready for primetime ?
On Thu, Oct 31, 2013 at 12:50 PM, Matthias Clasen mcla...@redhat.comwrote: On Thu, 2013-10-31 at 12:13 +0100, Tim Lauridsen wrote: I have tested gnome-software to see the current state, compaired to gpk in F19, there is a lot stuff there cant be done. 1. You cant install backgrounds / icons It is an application installer, first and foremost. Installing backgrounds/icons/themes is not a priority. That being said, 3.11 can install fonts and codecs. I know that it is an application installer, but user want to install content also and gpk can do that, so it is a regression in my world. gnome-software cant install extra backgrounds and icons https://bugzilla.redhat.com/show_bug.cgi?id=1025209 2. Not all application found in the menu, can be found under installed, you can search for them and find them, but cant remove them (ex. Document viewer) What menu ? And what application ? We have a notion of 'core app' - for things that 'come with the OS'. We don't allow to uninstall those. It feels inconsitance that i cant remove evince, but it can remove other gnome apps like boxes and documents gnome-software dont show all installed applications https://bugzilla.redhat.com/show_bug.cgi?id=1025250 3. if you search for 'icons' you get at lot of wrong positives, where there is no visible relation to icons in the text shown Search looks at keywords from desktop files in addition to descriptions and names. Would be good to see some concrete examples of the false positives you get. I only get gnome-tweak-tool and some icon-related font. search in package description, but dont show it https://bugzilla.redhat.com/show_bug.cgi?id=1021889 4. Description is missing from almost every application. Richard has pushed very hard for getting descriptions upstream - you may have seen his repeated posts on this topic. And we have made quite a bit of progress. But getting every application equipped with a good description, screenshots, and other metadata will take some time, and some help from the packagers and maintainers of those applications. I know Richard has pushed hard to get appdata for apps, but it do help the end user, if lot of apps in gnome-software dont have any descriptions. Look at System - File Tools - Caja-actions configuration tool How should an end user have a clue what this app does ? I think the current state will make Fedora look limitted for new Fedora users. Compared to Ubuntu, certainly. But compared to gpk-application F19, I don't think so. A tool like gnome-software targets novice enduser (IMHO) and more advanced user will tools like yum, dnf or yumex So I try to look at it like a novice end user, and they fill see a more friendly user interface, but they will not be able to find the things they are look for. The Fedora art team has done a great job find good extra background images, but you have to use a command line to install it on the current F10 gnome desktop, I is not a good user experiense i my book. Personal it is not a problem for me, but I would like Fedora to be as good as possible for new users, so i took some time to install the gnome desktop and check the state of thing and report the issues I have found. Tim -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
[perl-Types-Serialiser] Created tag perl-Types-Serialiser-0.03-2.fc18
The lightweight tag 'perl-Types-Serialiser-0.03-2.fc18' was created pointing to: ef9e8ef... Initial import (perl-Types-Serialiser-0.03-2) -- 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
[perl-Types-Serialiser] Created tag perl-Types-Serialiser-0.03-2.fc21
The lightweight tag 'perl-Types-Serialiser-0.03-2.fc21' was created pointing to: ef9e8ef... Initial import (perl-Types-Serialiser-0.03-2) -- 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
[perl-Types-Serialiser] Created tag perl-Types-Serialiser-0.03-2.el6
The lightweight tag 'perl-Types-Serialiser-0.03-2.el6' was created pointing to: ef9e8ef... Initial import (perl-Types-Serialiser-0.03-2) -- 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
Broken dependencies: perl-Language-Expr
perl-Language-Expr has broken dependencies in the rawhide tree: On x86_64: perl-Language-Expr-0.19-4.fc19.noarch requires perl(:MODULE_COMPAT_5.16.2) On i386: perl-Language-Expr-0.19-4.fc19.noarch requires perl(:MODULE_COMPAT_5.16.2) On armhfp: perl-Language-Expr-0.19-4.fc19.noarch requires perl(:MODULE_COMPAT_5.16.2) Please resolve this as soon as possible. -- 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: Is Gnome Software ready for primetime ?
On Thu, 2013-10-31 at 14:31 +0100, Tim Lauridsen wrote: On Thu, Oct 31, 2013 at 12:50 PM, Matthias Clasen mcla...@redhat.com wrote: On Thu, 2013-10-31 at 12:13 +0100, Tim Lauridsen wrote: I have tested gnome-software to see the current state, compaired to gpk in F19, there is a lot stuff there cant be done. 1. You cant install backgrounds / icons It is an application installer, first and foremost. Installing backgrounds/icons/themes is not a priority. That being said, 3.11 can install fonts and codecs. I know that it is an application installer, but user want to install content also and gpk can do that, so it is a regression in my world. 'Regression' does not really apply. gnome-software is not aiming to be a 1-1 replacement for gpk-application. Wrt to backgrounds, I would say that installing them in packages is really suboptimal, and we should look for ways to make backgrounds from online sources show up in the background panel. I know Richard has pushed hard to get appdata for apps, but it do help the end user, if lot of apps in gnome-software dont have any descriptions. Look at System - File Tools - Caja-actions configuration tool Get the cinnamon guys to fork the nautilus appdata ? I'm sure it will only need minor adjustments... :-) Personal it is not a problem for me, but I would like Fedora to be as good as possible for new users, so i took some time to install the gnome desktop and check the state of thing and report the issues I have found. Thanks for doing that. Your feedback is appreciated! -- 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: Fatal flaw in the udev paradigm?
Once upon a time, rran...@ihug.com.au rran...@ihug.com.au said: My USB GPS is a BU-353 which uses a pl2303 USB-Serial Controller (idVendor=067b, idProduct=2303). However, bugzilla report 878737 indicates this same interface chip is used on other devices such as RS232-USB adapters. The PL2303 chip and a few other USB RS232 chips are used in many devices (as well as straight USB-RS232 adapter cables), however most of them fail to properly identify themselvs. Most PL2303 devices don't even bother to set a serial number, much less sub-IDs, making it almost impossible to distinguish between them. This is not a flaw in udev; this is a flaw in how hardware makers use the chips. They essentially throw away a couple of decades of plug and play work to assume you'll only ever use their device (a lot of their Windows drivers grab every PL2303 in sight) or you'll manually configure everything. The best (and I use that term loosely) way to handle many of these poorly-designed devices is to always plug them in the same USB port, and then write udev rules that match particular device/bus/port combinations. -- 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: openssl multilib broken
On Thu, 31 Oct 2013 13:56:53 +0100, Reindl Harald wrote: currently on a x86_64 system distro-sync to F19 is broken i saw the same in F18 with updates-testing enabled on a machine with i686 packages some days ago and download the openssl packages for both archs from koji and doing a yum localupdate worked fine Error: Package: 1:openssl-1.0.1e-29.fc18.i686 (@/openssl-1.0.1e-29.fc18.i686/18) Where did you find openssl.i686 in the x86_64 repos? Did you download it from koji? The repo id in brackets is suspicious. Here is only openssl.x86_64 release -30.fc18: http://dl.fedoraproject.org/pub/fedora/linux/updates/testing/18/x86_64/ Here is only openssl.x86_64 release -28.fc18: http://dl.fedoraproject.org/pub/fedora/linux/updates/18/x86_64/ yum --enablerepo=updates-testing update openssl\* did not work because different versions for x86_64 and i686 and so i downloaded it from koji Why did you have openssl.i686 installed on x86_64 to begin with? You have messed up your installation. :-( Have you use rpm -Uvh instead of rpm -Fvh? Or why have you installed openssl.i686? It seems to me the openssl base package is not pulled in by the multilib composer (because openssl-devel only requires openssl-libs) but skype or whatever pulls dependencies Skype is not included with Fedora. Skype does not (and cannot) influence which packages are multilib'ed when the repos are composed. Skype 32-bit doesn't depend on openssl. What on your machine depends on 32-bit openssl and not openssl-libs? -- 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: Taskbot: TAP vs Subunit
= TAP = TAP is not unittest-specific, and is human-readable plaintext format. It also has just PASS/FAIL logic, but there is a possibility to add YAML 'metadata' to any result (since TAP v. 13). The real issue with TAP is Python support. There is a TAP-consumer library created as an example for PyParsing http://pyparsing.wikispaces.com/file/detail/TAP.py, but it does not support the v13 protocol, and is quite useless as such. TAP-producer library for Python https://github.com/rjbs/pytap is also using the old version (i.e. no YAML extensions), and seems to be dead (2 years since last update). It is also quite badly written. Doesn't autotest support TAP results storage? How do they do it? Lucas, can you comment? Thanks. ___ qa-devel mailing list qa-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/qa-devel
Re: openssl multilib broken
Am 31.10.2013 16:14, schrieb Michael Schwendt: On Thu, 31 Oct 2013 13:56:53 +0100, Reindl Harald wrote: currently on a x86_64 system distro-sync to F19 is broken i saw the same in F18 with updates-testing enabled on a machine with i686 packages some days ago and download the openssl packages for both archs from koji and doing a yum localupdate worked fine Error: Package: 1:openssl-1.0.1e-29.fc18.i686 (@/openssl-1.0.1e-29.fc18.i686/18) Where did you find openssl.i686 in the x86_64 repos? Did you download it from koji? The repo id in brackets is suspicious. Here is only openssl.x86_64 release -30.fc18: http://dl.fedoraproject.org/pub/fedora/linux/updates/testing/18/x86_64/ Here is only openssl.x86_64 release -28.fc18: http://dl.fedoraproject.org/pub/fedora/linux/updates/18/x86_64/ yum --enablerepo=updates-testing update openssl\* did not work because different versions for x86_64 and i686 and so i downloaded it from koji Why did you have openssl.i686 installed on x86_64 to begin with? You have messed up your installation. :-( Have you use rpm -Uvh instead of rpm -Fvh? Or why have you installed openssl.i686? the machine has a long history It seems to me the openssl base package is not pulled in by the multilib composer (because openssl-devel only requires openssl-libs) but skype or whatever pulls dependencies Skype is not included with Fedora. Skype does not (and cannot) influence which packages are multilib'ed when the repos are composed. Skype 32-bit doesn't depend on openssl. What on your machine depends on 32-bit openssl and not openssl-libs? i was the impression that in such cases all or nothing should be x86_64 and i686 or at least if both can be installed parallel they are also updated clean 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: Fatal flaw in the udev paradigm?
Can you wildcard the greylist so that modemmanager *never* runs? I haven't used a modem in decades but MM keeps mucking with all my serial-connected toys. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
[389-devel] lib389: cleanup __init__
Hi @all, I started investigating in mocking with fakeldap, and it seems an easy and viable way of adding unittests. A main issue is the DSAdmin.__init__ complexity. I thought - a long time ago actually - to remove from DSAdmin all cached references to backends, suffixes and configuration. If we want to add a cache layer we can do it afterward. And with some cache pattern. Let me know + Peace, R. -- Roberto Polli Community Manager Babel S.r.l. - http://www.babel.it T: +39.06.9826.9651 M: +39.340.652.2736 F: +39.06.9826.9680 P.zza S.Benedetto da Norcia, 33 - 00040 Pomezia (Roma) CONFIDENZIALE: Questo messaggio ed i suoi allegati sono di carattere confidenziale per i destinatari in indirizzo. E' vietato l'inoltro non autorizzato a destinatari diversi da quelli indicati nel messaggio originale. Se ricevuto per errore, l'uso del contenuto e' proibito; si prega di comunicarlo al mittente e cancellarlo immediatamente. -- 389-devel mailing list 389-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel
Re: openssl multilib broken
Michael Schwendt mschwendt at gmail.com writes: Skype is not included with Fedora. Skype does not (and cannot) influence which packages are multilib'ed when the repos are composed. Skype 32-bit doesn't depend on openssl. What on your machine depends on 32-bit openssl and not openssl-libs? In F16, when I had 32-bit packages (namely Skype and Fedora's wine) installed, I had both openssl.i686 and openssl.x86_64 installed, so openssl.i686 is pulled in, directly or indirectly, by either Skype or wine. It's easy to find out which one by trying to remove openssl.i686 to see what it wants to remove with 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: Taskbot: TAP vs Subunit
On 10/31/2013 01:23 PM, Kamil Paral wrote: = TAP = TAP is not unittest-specific, and is human-readable plaintext format. It also has just PASS/FAIL logic, but there is a possibility to add YAML 'metadata' to any result (since TAP v. 13). The real issue with TAP is Python support. There is a TAP-consumer library created as an example for PyParsing http://pyparsing.wikispaces.com/file/detail/TAP.py, but it does not support the v13 protocol, and is quite useless as such. TAP-producer library for Python https://github.com/rjbs/pytap is also using the old version (i.e. no YAML extensions), and seems to be dead (2 years since last update). It is also quite badly written. Doesn't autotest support TAP results storage? How do they do it? Autotest does support recording results in TAP format, due to the work made by a guy from AMD. Breaking the expectations that a TAP enabled test tool would just output tap on standard output, the autotest client can optionally produce files with the results in tap format, and those files can be further processed by other systems. Let me make some runs here and show you examples. Lucas, can you comment? Thanks. ___ qa-devel mailing list qa-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/qa-devel
Re: [fedora-arm] Announcing Fedora 19 ARM remix for Allwinner SOCs release 3
On Sun, 2013-10-13 at 23:29 +0200, Hans de Goede wrote: I'm very happy to announce the third release (r3) of my Fedora 19 ARM remix images for Allwinner A10, A10s, A13 and A20 based devices. This release is based on the official Fedora 19 Final for ARM images, with u-boot and kernel(s) from the linux-sunxi project: http://linux-sunxi.org/ http://people.fedoraproject.org/~jwrdegoede/a10-images/Fedora-19-a10-armhfp-r3.img.xz sha1sum: a57e5897e0c6047dbb473c438016d6364fd0709f Hi Hans, great job! I am trying to test your image on Cubieboard with 1GB RAM. So far, it was working quite good for me. I had the only trouble with yum update. It seems the mirrorlist variable is not working. I was trying to use baseurl instead. However, the default value wasn't working for me. There should be fedora-secondary instead of fedora in url. http://download.fedoraproject.org/pub/fedora/linux/fedora-secondary/releases/$releasever/Everything/$basearch/os/ I am not sure if this is an issue for anyone else. regards, -- Jozef Mlich jml...@redhat.com Associate Software Engineer - EMEA ENG Developer Experience Mobile: +420 604 217 719 http://cz.redhat.com/ Red Hat, Inc. -- 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: Taskbot: TAP vs Subunit
On 10/31/2013 01:23 PM, Kamil Paral wrote: = TAP = TAP is not unittest-specific, and is human-readable plaintext format. It also has just PASS/FAIL logic, but there is a possibility to add YAML 'metadata' to any result (since TAP v. 13). The real issue with TAP is Python support. There is a TAP-consumer library created as an example for PyParsing http://pyparsing.wikispaces.com/file/detail/TAP.py, but it does not support the v13 protocol, and is quite useless as such. TAP-producer library for Python https://github.com/rjbs/pytap is also using the old version (i.e. no YAML extensions), and seems to be dead (2 years since last update). It is also quite badly written. Doesn't autotest support TAP results storage? How do they do it? Lucas, can you comment? Thanks. Here you can see an example: $ client/autotest-local --tap client/tests/sleeptest/control 14:11:58 INFO | Writing results to /home/lmr/Code/autotest.git/autotest/client/results/default 14:11:58 INFO | Could not symlink init scripts (lack of permissions) 14:11:58 INFO | Not logging /proc/slabinfo (lack of permissions) 14:11:58 INFO | START timestamp=1383235918 localtime=Oct 31 14:11:58 14:11:58 INFO | START sleeptest sleeptest timestamp=1383235918 localtime=Oct 31 14:11:58 14:11:58 INFO | Not logging /proc/slabinfo (lack of permissions) 14:11:59 INFO | Not logging /proc/slabinfo (lack of permissions) 14:11:59 INFO | Not logging /var/log/messages (lack of permissions) 14:11:59 INFO | GOOD sleeptest sleeptest timestamp=1383235919 localtime=Oct 31 14:11:59 completed successfully 14:11:59 INFO | END GOOD sleeptest sleeptest timestamp=1383235919 localtime=Oct 31 14:11:59 14:11:59 INFO | END GOOD timestamp=1383235919 localtime=Oct 31 14:11:59 14:11:59 INFO | Report successfully generated at /home/lmr/Code/autotest.git/autotest/client/results/default/job_report.html $ cd /home/lmr/Code/autotest.git/autotest/client/results/default/ $ ls control control.state debug job_report.html meta.yml sleeptest status status.json status.tap sysinfo tap.tar.gz $ cat meta.yml file_order: - status.tap - sleeptest/status.tap - sleeptest/keyval.tap $ cat status.tap 1..2 ok 1 - sleeptest ok 2 - job $ cat sleeptest/status.tap 1..1 ok 1 - sleeptest $ cat sleeptest/keyval.tap 1..2 ok 1 - results --- param-seconds: 1 version: 1 ... ok 2 - results --- sysinfo-cmdline: BOOT_IMAGE=/vmlinuz-3.11.6-301.fc20.x86_64 root=/dev/mapper/fedora-root ro rd.lvm.lv=fedora/swap rd.md=0 rd.dm=0 rd.luks.uuid=luks-8c032338-feaa-456a-873c-a08c768b8861 vconsole.keymap=us rd.lvm.lv=fedora/root rhgb quiet LANG=en_US.utf8 sysinfo-memtotal-in-kb: 8061220 sysinfo-phys-mbytes: 8192 sysinfo-uname: 3.11.6-301.fc20.x86_64 #1 SMP Mon Oct 21 21:54:19 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux ... ___ qa-devel mailing list qa-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/qa-devel
Re: openssl multilib broken
On Thu, 31 Oct 2013 16:29:18 +0100, Reindl Harald wrote: Why did you have openssl.i686 installed on x86_64 to begin with? You have messed up your installation. :-( Have you use rpm -Uvh instead of rpm -Fvh? Or why have you installed openssl.i686? the machine has a long history Well, then it needs to be cleaned up from time to time. yum list extras as well as package-cleanup --orphans on an up-to-date installation shows all packages, which are not available in the enabled repos anymore. If you store everything you install directly via rpm in a local repo, you can keep track of packages that have been dropped by Fedora. Such as openssl.i686 for x86_64. Skype is not included with Fedora. Skype does not (and cannot) influence which packages are multilib'ed when the repos are composed. Skype 32-bit doesn't depend on openssl. What on your machine depends on 32-bit openssl and not openssl-libs? i was the impression that in such cases all or nothing should be x86_64 and i686 or at least if both can be installed parallel they are also updated clean Download mash src.rpm and examine it. The basic multilib repo compose strategy is to make merge all *-devel packages and their dependencies plus a few packages from a whitelist. It has been like that since Fedora Extras. Typically, openssl-devel requires openssl-libs, and if the openssl base package is not on the whitelist, something else would need to require it arch-specific. No i686 pkg in the x86_64 repo does currently: # repoquery --exactdeps --whatrequires 'openssl(x86-32)' # # repoquery --exactdeps --whatrequires 'openssl(x86-64)' openssl-perl-1:1.0.1e-22.fc20.x86_64 openssl-perl-1:1.0.1e-29.fc20.x86_64 # repoquery --exactdeps --whatrequires openssl|wc -l 73 -- 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: [389-devel] lib389: cleanup __init__
On 10/31/2013 09:58 AM, Roberto Polli wrote: Hi @all, I started investigating in mocking with fakeldap, and it seems an easy and viable way of adding unittests. A main issue is the DSAdmin.__init__ complexity. I thought - a long time ago actually - to remove from DSAdmin all cached references to backends, suffixes and configuration. If we want to add a cache layer we can do it afterward. And with some cache pattern. Part of the complexity is due to trying to keep data across a restart - that is, if you call stop() then start(), you want start() to automatically re-establish the connection - to do that, you need to store the credentials. Let me know + Peace, R. -- 389-devel mailing list 389-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel
Re: openssl multilib broken
On Thu, 31 Oct 2013 16:10:02 + (UTC), Andre Robatino wrote: In F16, when I had 32-bit packages (namely Skype and Fedora's wine) installed, I had both openssl.i686 and openssl.x86_64 installed, so Indeed. Up to F17, but not anymore since F18: http://archives.fedoraproject.org/pub/archive/fedora/linux/updates/17/x86_64/ http://dl.fedoraproject.org/pub/fedora/linux/updates/18/x86_64/ openssl.i686 is pulled in, directly or indirectly, by either Skype or wine. It's easy to find out which one by trying to remove openssl.i686 to see what it wants to remove with it. The 32-bit Skype rpm (for F16?) doesn't depend on openssl. But watch this on F20 x86_64: # repoquery --releasever=17 --exactdeps --whatrequires 'openssl(x86-32)' openssl-devel-1:1.0.0i-1.fc17.i686 openssl-devel-1:1.0.0k-1.fc17.i686 So, openssl-devel.i686 required openssl.i686 directly. There have been packaging changes/fixes related to 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: openssl multilib broken
On Thu, 2013-10-31 at 17:32 +0100, Michael Schwendt wrote: But watch this on F20 x86_64: # repoquery --releasever=17 --exactdeps --whatrequires 'openssl(x86-32)' openssl-devel-1:1.0.0i-1.fc17.i686 openssl-devel-1:1.0.0k-1.fc17.i686 So, openssl-devel.i686 required openssl.i686 directly. There have been packaging changes/fixes related to that. Yes, at some point openssl-libs was split out of openssl. -- Mathieu -- 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: [389-devel] lib389: cleanup __init__
Hi Rich, On Thursday 31 October 2013 10:32:13 Rich Megginson wrote: I thought - a long time ago actually - to remove from DSAdmin all cached references to backends, suffixes and configuration. Part of the complexity is due to trying to keep data across a restart I agree with credential caching - as they should be quite unmutable, and I was talking about __initPart2() which is called by __init__. Are all the __initPart2() attributes essential? Peace, R: -- Roberto Polli Community Manager Babel S.r.l. - http://www.babel.it T: +39.06.9826.9651 M: +39.340.652.2736 F: +39.06.9826.9680 P.zza S.Benedetto da Norcia, 33 - 00040 Pomezia (Roma) CONFIDENZIALE: Questo messaggio ed i suoi allegati sono di carattere confidenziale per i destinatari in indirizzo. E' vietato l'inoltro non autorizzato a destinatari diversi da quelli indicati nel messaggio originale. Se ricevuto per errore, l'uso del contenuto e' proibito; si prega di comunicarlo al mittente e cancellarlo immediatamente. -- 389-devel mailing list 389-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel
Re: [389-devel] lib389: cleanup __init__
On 10/31/2013 10:35 AM, Roberto Polli wrote: Hi Rich, On Thursday 31 October 2013 10:32:13 Rich Megginson wrote: I thought - a long time ago actually - to remove from DSAdmin all cached references to backends, suffixes and configuration. Part of the complexity is due to trying to keep data across a restart I agree with credential caching - as they should be quite unmutable, and I was talking about __initPart2() which is called by __init__. Are all the __initPart2() attributes essential? No. You could do lazy evaluation of those fields. For example, instead of having a .dbdir field, have a .getdbdir() member that would do an ldapsearch if .dbdir is None. Peace, R: -- 389-devel mailing list 389-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel
Re: [389-devel] lib389: cleanup __init__
On Thursday 31 October 2013 10:40:25 Rich Megginson wrote: Are all the __initPart2() attributes essential? No. You could do lazy evaluation of those fields. For example, instead of having a .dbdir field, have a .getdbdir() member that would do an ldapsearch if .dbdir is None. That's good. We could put that in Config. Peace, R: -- Roberto Polli Community Manager Babel S.r.l. - http://www.babel.it T: +39.06.9826.9651 M: +39.340.652.2736 F: +39.06.9826.9680 P.zza S.Benedetto da Norcia, 33 - 00040 Pomezia (Roma) CONFIDENZIALE: Questo messaggio ed i suoi allegati sono di carattere confidenziale per i destinatari in indirizzo. E' vietato l'inoltro non autorizzato a destinatari diversi da quelli indicati nel messaggio originale. Se ricevuto per errore, l'uso del contenuto e' proibito; si prega di comunicarlo al mittente e cancellarlo immediatamente. -- 389-devel mailing list 389-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel
Re: Fatal flaw in the udev paradigm?
On 10/31/2013 02:03 AM, rran...@ihug.com.au wrote: I have run into an issue which seems to call into question the udev paradigm for USB devices. In my case it has ramifications in ModemManager and gpsd packages, but I see it as a fundamental problem with udev which is in all current versions of Fedora. My USB GPS is a BU-353 which uses a pl2303 USB-Serial Controller (idVendor=067b, idProduct=2303). However, bugzilla report 878737 indicates this same interface chip is used on other devices such as RS232-USB adapters. If the device is a GPS you do not want ModemManager run on it (bugzilla 1023234) but you do want gpsctl to tell gpsd about it when it is plugged in. If it is a RS232 adapter the opposite is true (bugzilla 878737). Note that it is reported that the DU-353 can be bricked if the wrong thing is written to it. After looking at the lsusb -v output for my BU-353 and the output for RS232 devices reported on the net, I do not see any way to distinguish between the two different types of devices that udev could use to tell them apart. Unless I am missing something this seems like a fatal flaw in the udev paradigm. As the others have said, there's no way to determine what's sitting behind those serial controllers so it's not a problem with udev but with the hardware it has to handle. The default udev setting is, or at least used to be, designed for the most common case, which turns out wrong for you. No matter what udev does, someone is not going to get their device auto-configured, so the right choice is to handle the most common case. Now, it's possible that modems aren't just used much any more, so that requiring manual scan would make sense, and udev makes it possible. By the way, it seems to me that on a computer with no modems, one should simply uninistal ModemManager: yum erase ModemManager -- 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: Fatal flaw in the udev paradigm?
On Thu, 2013-10-31 at 11:49 -0400, DJ Delorie wrote: Can you wildcard the greylist so that modemmanager *never* runs? I haven't used a modem in decades but MM keeps mucking with all my serial-connected toys. You can do anything you want with the udev rules. Just put them in /etc/udev/rules.d. But better yet, mind sharing which toys you have so we can update the black/greylists as appropriate? Thanks! Dan -- 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: Fatal flaw in the udev paradigm?
But better yet, mind sharing which toys you have so we can update the black/greylists as appropriate? I make them myself using FTDI chips, usually, and they talk plain RS-232 using terminal emulators and such: http://www.delorie.com/electronics/ I also get a lot of eval boards with usb-serial chips on them. They're plain serial ports, but they're not modems. IMHO the assumption that every serial port might be a modem is the wrong assumption these days. -- 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: openssl multilib broken
Am 31.10.2013 17:27, schrieb Michael Schwendt: On Thu, 31 Oct 2013 16:29:18 +0100, Reindl Harald wrote: Why did you have openssl.i686 installed on x86_64 to begin with? You have messed up your installation. :-( Have you use rpm -Uvh instead of rpm -Fvh? Or why have you installed openssl.i686? the machine has a long history Well, then it needs to be cleaned up from time to time. until today i thought it is as clean as possible because a self-maintained meta-package and anything which get listed by package-cleanup --leaves --all is removed but sadly you can't do Requires: package.x86_64 explicitly this way and so Requires: openssl catched both yum list extras as well as package-cleanup --orphans on an up-to-date installation shows all packages, which are not available in the enabled repos anymore. If you store everything you install directly via rpm in a local repo, you can keep track of packages that have been dropped by Fedora. Such as openssl.i686 for x86_64. i was the impression that in such cases all or nothing should be x86_64 and i686 or at least if both can be installed parallel they are also updated clean Download mash src.rpm and examine it. The basic multilib repo compose strategy is to make merge all *-devel packages and their dependencies plus a few packages from a whitelist. It has been like that since Fedora Extras. Typically, openssl-devel requires openssl-libs, and if the openssl base package is not on the whitelist, something else would need to require it arch-specific. No i686 pkg in the x86_64 repo does currently: # repoquery --exactdeps --whatrequires 'openssl(x86-32)' # # repoquery --exactdeps --whatrequires 'openssl(x86-64)' openssl-perl-1:1.0.1e-22.fc20.x86_64 openssl-perl-1:1.0.1e-29.fc20.x86_64 # repoquery --exactdeps --whatrequires openssl|wc -l thank you for that worthful input! 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: Fatal flaw in the udev paradigm?
On Thu, 2013-10-31 at 12:50 -0400, Przemek Klosowski wrote: On 10/31/2013 02:03 AM, rran...@ihug.com.au wrote: I have run into an issue which seems to call into question the udev paradigm for USB devices. In my case it has ramifications in ModemManager and gpsd packages, but I see it as a fundamental problem with udev which is in all current versions of Fedora. My USB GPS is a BU-353 which uses a pl2303 USB-Serial Controller (idVendor=067b, idProduct=2303). However, bugzilla report 878737 indicates this same interface chip is used on other devices such as RS232-USB adapters. If the device is a GPS you do not want ModemManager run on it (bugzilla 1023234) but you do want gpsctl to tell gpsd about it when it is plugged in. If it is a RS232 adapter the opposite is true (bugzilla 878737). Note that it is reported that the DU-353 can be bricked if the wrong thing is written to it. After looking at the lsusb -v output for my BU-353 and the output for RS232 devices reported on the net, I do not see any way to distinguish between the two different types of devices that udev could use to tell them apart. Unless I am missing something this seems like a fatal flaw in the udev paradigm. As the others have said, there's no way to determine what's sitting behind those serial controllers so it's not a problem with udev but with the hardware it has to handle. The default udev setting is, or at least used to be, designed for the most common case, which turns out wrong for you. No matter what udev does, someone is not going to get their device auto-configured, so the right choice is to handle the most common case. Now, it's possible that modems aren't just used much any more, so that requiring manual scan would make sense, and udev makes it possible. By the way, it seems to me that on a computer with no modems, one should simply uninistal ModemManager: Not just a computer with no modems, but a computer into which you would never plug a modem and use it. These days, there aren't many 56k/POTS devices, but the vast vast majority are WWAN modems. And these are sometimes, especially in embedded cases, driven by generic serial converters like pl2xxx. If you're on a server, and that server does not have any SMS me when you're down functionality, then you may not want ModemManager installed there. But we'd also like to hear about devices that MM probes-but-shouldn't-probe so we can black/greylist them as appropriate. Dan -- 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: Taskbot: TAP vs Subunit
On 10/31/2013 02:27 PM, Josef Skladanka wrote: Lucas, do you use any library for producing TAP format? No, at least not in the sense of an external project. Producing TAP in the client is an autotest specific implementation. It is the TAPReport() object defined in: https://github.com/autotest/autotest/blob/master/client/shared/base_job.py#L682 Also, do you have any TAP parser, or do you just emit it? Currently, autotest only outputs TAP, there's no parser available. Cleber from my time was evaluating writing one, but we didn't go forward with it. Matěj Cepl, also a Red Hat employee, implemented one parser at some point, but I think he felt discouraged because people did not give feedback to him (he did ask, though). I for one am also guilty of not following up with his work. He used to have it on his github account, but I can't seem to find it. https://github.com/mcepl?tab=repositories I was looking for something in Python, but all I got is either outdated, or non-complete. I wish we had a better answer to give you, but unfortunately we don't. ___ qa-devel mailing list qa-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/qa-devel
Re: Taskbot: TAP vs Subunit
On Thu, 31 Oct 2013 07:17:03 -0400 (EDT) Josef Skladanka jskla...@redhat.com wrote: Bah, just realized this only went to Josef the first time I sent it. He gets two copies! Tim (and of course the rest of the gang ;)), During our chat with Tim, we agreed that we'd really like to use some standardized 'output format' for the tests in Taskbot, to be a bit more programming-language/results-store-implementation agnostic. We knew about two options - TAP http://testanything.org/wiki/index.php/Main_Page and Subunit https://pypi.python.org/pypi/python-subunit. = Subunit = At least in Python is quite tightly coupled with unittest, both ideologically and practically. I was unable to find a way to just produce a Subunit stream without the need of actually running a testsuite. The format is (basically) just plain PASS/FAIL/INFO/..., and there is possibility to add some 'details'results. It should also be possible to add an attachment to the end of the stream, but no result-specific data can be added (IMO). Also Subunit is now in the process of transition to new implementation, which now should fix some issues with concurrency, add more result-states, etc., but will be binary, so human readability would quite suffer. I do not really feel that this is a good match for our needs (at least without any significant hacking) Yeah, this matches what I remember finding when I looked into this a couple of months ago. It looks like a better protocol overall but it's going to be quite a bit more upfront work to support than TAP. I know that openstack's test suite uses subunit for nova and neutron [1] [1] https://wiki.openstack.org/wiki/Testr Subunit has been recently added to the fedora repos but I suppose that's of little utility for us if we end up having to re-implement parts to get away from UnitTest. = TAP = TAP is not unittest-specific, and is human-readable plaintext format. It also has just PASS/FAIL logic, but there is a possibility to add YAML 'metadata' to any result (since TAP v. 13). The real issue with TAP is Python support. There is a TAP-consumer library created as an example for PyParsing http://pyparsing.wikispaces.com/file/detail/TAP.py, but it does not support the v13 protocol, and is quite useless as such. TAP-producer library for Python https://github.com/rjbs/pytap is also using the old version (i.e. no YAML extensions), and seems to be dead (2 years since last update). It is also quite badly written. Another option for TAP emission is bayeux [2] which was created for a better, less perl-ish interface to tap [3]. It might be worth asking mcepl if he has any thoughts on TAP vs. subunit vs. something else. [2] http://luther.ceplovi.cz/git/bayeux.git/ [3]http://lists.idyll.org/pipermail/testing-in-python/2012-March/004881.html = Result = Although neither choice is ideal, I feel that TAP would be the better choice, even though it would mean implementing our own producer/parser. Also the TAP is really simplistic format, so creating a TAP output should be quite easy even in any programming language. I think that TAP is certainly appears to be the simpler solution for now and I suspect it's a bit more widely used than subunit. As long as the amount of work required to have a TAP emitter and parser isn't crazy, I agree that TAP is a better choice. It is possible that I somehow utterly misunderstood the Subunit concept, so it might be useful to contact some QAs currently using it (I thing Tim mentioned something about OpenStack?), or contact the developer directly. I suspect that you found this when searching but there's a direct comparison of the two by someone with more of a TAP background: http://www.kinoshita.eti.br/2011/06/04/a-comparison-of-tap-test-anything-protocol-and-subunit.html Thanks for looking into this, Tim signature.asc Description: PGP signature ___ qa-devel mailing list qa-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/qa-devel
Re: Fatal flaw in the udev paradigm?
On Thu, 2013-10-31 at 13:08 -0400, DJ Delorie wrote: But better yet, mind sharing which toys you have so we can update the black/greylists as appropriate? I make them myself using FTDI chips, usually, and they talk plain RS-232 using terminal emulators and such: http://www.delorie.com/electronics/ I also get a lot of eval boards with usb-serial chips on them. They're plain serial ports, but they're not modems. IMHO the assumption that every serial port might be a modem is the wrong assumption these days. I use arduinos in my rare spare time, the are not modems, but they use serial ports. I think the majority of devices the use serial ports in the makers era are definitely not modems. Probably worth not consider them as such by default unless explicitly configured in network settings. Simo. -- Simo Sorce * Red Hat, Inc * New York -- 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: Canonical copy of config.guess/config.sub
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
El Fri, 25 Oct 2013 13:59:37 +0200
Phil Knirsch pknir...@redhat.com escribió:
On 10/25/2013 12:07 PM, Marcin Juszkiewicz wrote:
W dniu 22.10.2013 17:26, Ralf Corsepius pisze:
Also, automake-based projects receive the versions bundled with
automake, when running automake rsp. autoreconf.
*IF* they run autoreconf. I am working on getting software built for
AArch64 for over a year now. Main issue is all those projects which
ship old, long-time-deprecated copies of config.{guess,sub} files.
Sure, they are new enough for most of architectures and operating
systems now in use but not for new ones.
And %configure macro updates them from /usr/lib/rpm/redhat/ anyway
which covers most of situations but for some we need to copy those
files by hand because authors think that they are smart and do lot
of crazy tricks like:
1. ln -sf ../configure . (so %configure tries . instead of ..)
2. shipping multiple copies of gnu-config files in any random
versions 3. shipping both config.{guess,sub} and
configure.{guess,sub} with use of the second ones
And such list can go on and on...
Brent Baude from IBM has proposed a bit of a different approach a few
days ago on the secondary mailing list for their work and bring up of
Power 64bit Little endian:
https://lists.fedoraproject.org/pipermail/secondary/2013-October/002628.html
A very brief summary of what they did was that, instead of tackling
the problem on the autoFOO and libtool side they modified the linker
itself to always claim to be able to generate shared libraries, even
if the arch was actually wrong. In a confined and controlled
environment where you control the linker and the linker actually
really KNOWS it can generate correct shared libraries for that arch
this works just as well.
The huge benefit here is that you only need to modify the linker,
everything else afterwards simply falls into place and just
works(tm). They have already tried this with a large number of
packages and haven't seen a single issue with that approach.
Obviously you'd want this as a temporary solution until either
Florian's approach would get adopted and shared by upstream libtool
or the majority of packages have gotten an upstream update that
picked up the latest config.sub and config.guess to work properly on
your new architecture.
you still need to patch config.guess and config.sub because when you
get to koji it will say the arch is ppc64le and configure will puke
because the arch is unknown.
Dennis
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)
iQIcBAEBAgAGBQJScrZ9AAoJEH7ltONmPFDRaygQAL8QB7JQPVJ/KqFG6q7iKkby
3XPglXnhkz+6F5dry3pcb1RJcB468r7AUiUPASp/WyOwAbunn3ZsphDVnzeGGzg0
8zNbXm6Ot2QYKCN0XipdGOF++5qK3vp+81zROUNwe+rKuMClauHjEKwvYHZeRaO8
/EYR15ON6QhyDxpAt8ImIqfeuTtEFhcvgur7sUxHItaotejiF0neYgsOToVm9Dvx
mlAniX2LIwAHIQElq750m+ac4lNqudTMD1WMOAupj+sO2pOdfAWvsLZ8eItvYI0y
XcD5Nn0Rjij+Qk4SG4Rvhon18flATGAJchh48k/9rIyGQ3dUgmxlOGPSeGQy/IOD
4IGnXDa1BhCMPMaQ346gfjHUzo1xkLyR8vvvV11ar7WkKF9mPMxBQXThOWG3FGHg
HChYZ7iKHe9dH1fHd32AHIziRw/OgXJKKAwaTb5Fa9yl8lzMEFKAYKZhUTTOB0WM
VeGs9LlAVTYKHv66XIMKOnjZoi+3Q7kuJJQCrv4pVU+OviYbd+kw5dJEmfUrK54W
+geiluUJfvlH1twe6k53ZmvqqtW14+7vuu4dhS3fsYpKymBez8y+FBDc0l91eWP6
FPBdBHakiqnJbkQLpB9N9F4tYPWWfBqMziNXuXM0xsabYUEjhQWL8Hxyia73Smdy
B4Cvf+YJS41JmEtXBsML
=Xi7r
-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 search
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 El Wed, 30 Oct 2013 14:29:25 -0500 Michael Cronenworth m...@cchtml.com escribió: Frankie Onuonga wrote: I am writing in regards to something I had written about two months ago. This in regards to the search engine. https://fedorahosted.org/fedora-infrastructure/ticket/1055#trac-add-comment I think we need to seriously fix this thing once and for all. I am looking at designing a solution for us. I however would like to start from the basics. We will need to look at the solutions that are present at the current time. This should allow us to critic and analyse them. I will then take this issue into the meeting for voting and whatever is decided is what I shall implement. Kindly do advice if you have any pointers on this project. I however must be honest and say it will take me about 2 months to complete when i start because I have a day job elsewhere. This does not mean I will not want assistance. As always assistance is highly appreciated. I hope this will be fruitful so we can close this once and for all. Or should I say until we need a revision done. What about using a custom Google search engine? https://www.google.com/cse/ simple answer, its not open source Dennis -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) iQIcBAEBAgAGBQJScrd2AAoJEH7ltONmPFDRXL8P/RaWGBi6aXj/yeyXSa0OPBsF 8k8w5X/dIK0SHyYmefktBLr1gJgJeiQR0FMrk0SzmmBEUWMsZ64fYtDUdmtHUTi/ NgpFW4hcqwp2SuuRRelc2pwaT/TjvV3aeYzyZ5jDkkIsOP//7vxEp0k85xcXnxfp RLGWuZ/yIuCv3f8psdQw/NIh0AwJixLBtdLxJi/8fxj7YrLS7+ui8a/Nlm5jjHN5 AjZn88f1cuSBNn4sLpvUXUIFzufSGkVLcTasnvXMTU6wzNYDZkXGGJBTgb0B/+1l suoC8HtuSaLQvtwW6OqNQFdBlvWlbpEuKU+UIqVcVWhkCBitZY0WuDlrORZuFKfl sSAVgcB3Fha5Qx4aBkRMshZ9FrhdeU58EpZS55qRsuriK/clU1oC2KOTZ/Cw8H4O KuH8jUTM50X4uHmh8LdGN/eLFI/WrRPPQbmyUUWKx7ymjeR8F8EznoG+PHRDmW+q xOhMAzA7XxMNBG+gWM59b+EN2EBVKSaBbTTbNbzd+LI7SDnvs762AlJMZFvZBWco b4S6Fdw2jG6uX+90MdmL1i0lkB8nuQWF4hfbJgUQXI1c1TqGUymuhzXcvvox214y Vb2NHT8VBC5DsXfKPbP79bNgoJjBz5B+QJ8QtfMtiucN8PsEF0e2MaNXWE+kQpe9 Te2OjwUGwDVIRf2AwG5w =ZeYQ -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
[Test-Announce] Fedora 20 Beta to slip by one week
Today at Go/No-Go meeting it was decided to slip Fedora 20 Beta release by one week due to unresolved blocker bugs not being fixed by the time of meeting. Due to constrained schedule, shorter slip was considered but with limited QA resources availability, it was decided to slip for a full week. FESCo will be contacted for further schedule adjustments. Beta release is now planned for Nov-12. More details in meeting minutes [2]. The next Go/No-Go meeting is on Thursday, Nov 07, the same time in #fedora-meeting-2 channel. [1] http://qa.fedoraproject.org/blockerbugs/milestone/20/beta/buglist [2] http://meetbot.fedoraproject.org/fedora-meeting-2/2013-10-31/f20_beta_gono-go_meeting.2013-10-31-17.00.html [3] https://fedoraproject.org/wiki/Releases/20/Schedule ___ test-announce mailing list test-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/test-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
Packages have proxy word.
بسم الله الرّحمن الرّحيم Hi, The result of updating Fedora by yum is fail !! When any package have proxy word marked to (install or update) , error message will appear with http 403 error forbidden. In my country Syria (maybe others) all URLs have proxy word are forbidden and couldn't open by default way. In Fedora there are two common packages and have many updates: libproxy - sssd-proxy . Can to rename to : libproxies - sssd-proxies Or something else. Then do new rule to write proxies instead of proxy, at Fedora packaging guidlines. Regards -=-=-=-=-=- Mosaab Alzoubi Senior of Linux Arab Community http://linuxac.org Member of Ojuba Project http://ojuba.org Member of Arab Eyes project http://arabeyes.org Maintainer of Almasa project http://linux.softpedia.com/progMoreBy/Publisher-Almasa-47122.html Maintainer of Arabic Translations in : Wine - VLC - KDE etc Also member of Fedora Arabic translations 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
ModemManager and generic USB hardware (was: Fatal flaw in the udev paradigm?)
On Thursday 31 October 2013 12:00:10 Dan Williams wrote:
If you're on a server, and that server does not
have any SMS me when you're down functionality, then you may not want
ModemManager installed there.
+1
But also in other cases, like the following:
* Software/hardware developer use a Linux laptop
* They remove ModemManager so it won't mess with their electronic
hardware testing.
* Later on, they are on the road and need something urgently.
* No problem, we have GSM modem, but... it's not working...
* No problem, we'll re-install ModemManager, but... we need a chicken
for this egg (or maybe vice versa ;-)
All of this just begs for a global disable flag for ModemManager:
* This should probably go into NetworkManager.
* It should be a boolean runtime flag, e.g: some dbus property.
* This way it could be exposed in UI (enable/disable modems).
But we'd also like to hear about devices
that MM probes-but-shouldn't-probe so we can black/greylist them as
appropriate.
While this will solve many problematic cases, it would still leave
a lot of unresolved cases:
* Either permanently (because of broken hardware)
* Or temporarily (until packages with updated graylist are installed).
[yes, the admin may create something temporary in /etc/udev/rules.d
but I'm talking from a *user* pov]
It looks like ModemManager should be able to pass some decision to the end
user.
Here is one possible model for doing this:
* All *potential* modem devices (serial ports, known USB id's, etc.) that
are reported to ModemManager build a list of Possible modems.
* However, ModemManager scan all this list *only if* a scan_all_devices
property is true -- in this case, it behaves like today.
* Even when this property is false, the user would be able to call
a new ScanDevice(dev) method to scan *a specific* device (from
the possible modems list).
Combining the two changes with the suggested global disable flag, would allow
a UI (e.g: nm-applet) to provide an interface which is both easy to grasp
and highly flexible (IMHO):
* With modems disabled -- everything is silent.
* With modems enabled -- the user can see a list of devices:
- The UI may optionally augment this list with some sysfs properties if
they exist (e.g: idProduct for USB devices, or the strings from the
USB hardware database, etc.) -- this extra info is public anyway and
doesn't require any MM involvement, it's just a UI thingy.
- If scan_all_devices is true, the UI may augment the list display
during the scan by MM. E.g: gray out devices that haven't responded yet,
show some progress for currently scanned device, display SIM information
when MM read it, etc.)
- OTOH, if scan_all_devices is false, the user may click a specific
device from this list to start ScanDevice(dev) on it.
* Optionally, the UI may implement further selection rules. For example:
- Allow the user to blacklist specific devices in the UI.
- This blacklist would be a UI list (i.e: client side).
- The UI would simply ScanDevice(dev) all other devices, so MM wouldn't
know/care about the extra granularity that was added by the UI.
Last, unrelated, suggested MM udev tweak:
* A lot of USB modems have several USB interfaces which translates to several
/dev/ttyUSB* etc.
* Some of the drivers (e.g: ZTE) provide a way for udev rules to hint them
about the preferred MODEM interface, e.g:
... ENV{.MM_USBIFNUM}==00, ENV{ID_MM_ZTE_PORT_TYPE_MODEM}=1
* Since there are so many no-name/broken USB modems out there, it would be
nice if this provision could be re-factored so it would apply to any USB
modem plugin (including the generic one):
... ENV{.MM_USBIFNUM}==00, ENV{ID_MM_PORT_TYPE_MODEM}=1
Now I wait to see:
A. If these ideas are just stupid and I don't understand anything about MM.
B. Or they are OK, but MM people cannot be expected to implement any
random nice idea suggested by someone on the Internet...
If it's B. -- please let me know and I'll try to see if I can prototype
something that may even function on some lucky days ;-)
Thanks,
--
Oron Peled Voice: +972-4-8228492
o...@actcom.co.il http://users.actcom.co.il/~oron
Microsoft: We make virii work!
--
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: Packages have proxy word.
Hi, Renaming packages it is not user friendly thing because of few reasons: - there's some documentation/blog posts etc that use these names - this will break installation scripts - poeple who use these packages are familiar with these names What if your country also ban proxies word? 2013/11/1 مصعب الزعبي moc...@hotmail.com بسم الله الرّحمن الرّحيم Hi, The result of updating Fedora by yum is fail !! When any package have proxy word marked to (install or update) , error message will appear with http 403 error forbidden. In my country Syria (maybe others) all URLs have proxy word are forbidden and couldn't open by default way. In Fedora there are two common packages and have many updates: libproxy - sssd-proxy . Can to rename to : libproxies - sssd-proxies Or something else. Then do new rule to write proxies instead of proxy, at Fedora packaging guidlines. Regards -=-=-=-=-=- Mosaab Alzoubi Senior of Linux Arab Community http://linuxac.org Member of Ojuba Project http://ojuba.org Member of Arab Eyes project http://arabeyes.org Maintainer of Almasa project http://linux.softpedia.com/progMoreBy/Publisher-Almasa-47122.html Maintainer of Arabic Translations in : Wine - VLC - KDE etc Also member of Fedora Arabic translations 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 -- Best regards, Michal http://eventhorizon.pl/ -- 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: Packages have proxy word.
Proxies not banned. Date: Fri, 1 Nov 2013 00:20:35 +0100 Subject: Re: Packages have proxy word. From: mkkp...@gmail.com To: devel@lists.fedoraproject.org Hi, Renaming packages it is not user friendly thing because of few reasons: - there's some documentation/blog posts etc that use these names - this will break installation scripts - poeple who use these packages are familiar with these names What if your country also ban proxies word? 2013/11/1 مصعب الزعبي moc...@hotmail.com بسم الله الرّحمن الرّحيم Hi, The result of updating Fedora by yum is fail !! When any package have proxy word marked to (install or update) , error message will appear with http 403 error forbidden. In my country Syria (maybe others) all URLs have proxy word are forbidden and couldn't open by default way. In Fedora there are two common packages and have many updates: libproxy - sssd-proxy . Can to rename to : libproxies - sssd-proxies Or something else. Then do new rule to write proxies instead of proxy, at Fedora packaging guidlines. Regards -=-=-=-=-=- Mosaab Alzoubi Senior of Linux Arab Community http://linuxac.org Member of Ojuba Project http://ojuba.org Member of Arab Eyes project http://arabeyes.org Maintainer of Almasa project http://linux.softpedia.com/progMoreBy/Publisher-Almasa-47122.html Maintainer of Arabic Translations in : Wine - VLC - KDE etc Also member of Fedora Arabic translations 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 -- Best regards, Michal http://eventhorizon.pl/ -- 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: Packages have proxy word.
On Fri, Nov 01, 2013 at 01:08:33AM +0200, مصعب الزعبي wrote: بسم الله الرّحمن الرّحيم Hi, The result of updating Fedora by yum is fail !! When any package have proxy word marked to (install or update) , error message will appear with http 403 error forbidden. In my country Syria (maybe others) all URLs have proxy word are forbidden and couldn't open by default way. I think you'll have to use a... proxy to work around this problem. Or maybe it'll be enough to use a https connection to the mirror. Zbyszek -- 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: Packages have proxy word.
On Oct 31, 2013 6:08 PM, مصعب الزعبي moc...@hotmail.com wrote: بسم الله الرّحمن الرّحيم Hi, The result of updating Fedora by yum is fail !! When any package have proxy word marked to (install or update) , error message will appear with http 403 error forbidden. In my country Syria (maybe others) all URLs have proxy word are forbidden and couldn't open by default way. In Fedora there are two common packages and have many updates: libproxy - sssd-proxy . Can to rename to : libproxies - sssd-proxies Or something else. Then do new rule to write proxies instead of proxy, at Fedora packaging guidlines. Regards -=-=-=-=-=- Mosaab Alzoubi You might have some luck with rsync. I *think* there's some tooling out there to enable a mirror with only your required packages; if not, you can create a wrapper script for it. Something like --excludes=$(yum list all - yum list installed) might do. [not actual code] --Pete -- 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: Packages have proxy word.
Censorship? I think we have no reason to change the package name because of some governments‘ being evil. Have you tried opening a ssh tunnel proxy for firewall breaking? 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
Fedora engineering manager
Hi Fedora folks, Hopefully some of you know me, possibly as a previous Fedora Project Leader at Red Hat. If you don't, then salutations, and please feel free to check out my Fedora wiki page[1] for my background. :-) As of next Monday, I'll be the reporting manager for Fedora Engineering team members -- those folks who work on Fedora full time in the Engineering department of Red Hat, other than the Fedora Project Leader, Robyn Bergeron. This doesn't really affect anything in the community, but I want to ensure that change is transparent to the community. These folks previously reported to Tom 'spot' Callaway, who remains at Red Hat, and has kindly given me his good wishes in the new job. Of course, we fully expect to continue working together around the Fedora community. I'm lucky to be coming on board with an awesome team full of great people, and I'm excited about working with all of them! Of course there will be some transition time while I manage the backfill for my other work at Red Hat, but you'll start seeing more of me around here in the near future. Sorry for the interruption -- now back to the normal Fedora stuff. = = = [1] https://fedoraproject.org/wiki/User:Pfrields -- Paul W. Frieldshttp://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 http://redhat.com/ - - - - http://pfrields.fedorapeople.org/ The open source story continues to grow: http://opensource.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
Re: Fedora engineering manager
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 El Thu, 31 Oct 2013 22:42:52 -0400 Paul W. Frields sticks...@gmail.com escribió: Hi Fedora folks, Hopefully some of you know me, possibly as a previous Fedora Project Leader at Red Hat. If you don't, then salutations, and please feel free to check out my Fedora wiki page[1] for my background. :-) As of next Monday, I'll be the reporting manager for Fedora Engineering team members -- those folks who work on Fedora full time in the Engineering department of Red Hat, other than the Fedora Project Leader, Robyn Bergeron. This doesn't really affect anything in the community, but I want to ensure that change is transparent to the community. Just so its clear, I think I'm the only other person who works full time on Fedora at Red Hat, but I'm in a different part of the organisation and have a different reporting structure. These folks previously reported to Tom 'spot' Callaway, who remains at Red Hat, and has kindly given me his good wishes in the new job. Of course, we fully expect to continue working together around the Fedora community. I'm lucky to be coming on board with an awesome team full of great people, and I'm excited about working with all of them! Of course there will be some transition time while I manage the backfill for my other work at Red Hat, but you'll start seeing more of me around here in the near future. Sorry for the interruption -- now back to the normal Fedora stuff. Welcome back and Congratulations. I hope your ready to jump in :) Dennis -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) iQIcBAEBAgAGBQJScxZNAAoJEH7ltONmPFDRowUP/1NDyyMFFC+fgsytHobIrGGx UWBl/fM6h6RJeQ+6vbeiDRCOlrVLJrRhbCqrSMO0HucTeBczyU4nXK6Qw631lXmU /eHNOPVUhOAz97TzyZJ0TmpI9QTP5hWdfzNh+rqxZciJCGAM1+XvThvpMSnYrnnT XeyvFrblmWGgjH1QUBxapXSrTE+h1wRdf1fyZn8mW+10+aRsFPWiVotvAjJbVyN/ Vi8rOSMaysGgujfKg4xynmiGYIL3LEUJFKGcZ7msTgc5UtG0ETk3JMMoJciIWKoo FHJPFSgm+lViBge+pCQorXU/sQZyiLRxmKOwPbqidXkTz/Ymsw9/dEO9Hz9hsgqQ qEnfopvTcx6fnFW7NEAGDe8YG0GResZwVSr3VY2L6JGQgxBBMxA5D+8i61TayNHV SgDCgYrluk+7TABA3sAB3M3CJrDgVbsNHBRbTbciDLIRzcR18gBtu88h0O3+qC+6 0w58QlZToVkHhpJMIt06njt5CLsrmZCHAMw5A3WExt9/FlKw8qMQeB4p8Pk0mGyV YwlpHNxId6n0WkvKYgE4nOyNfzd8rGX+HV9l6WlPo7qBFBAoLaqLsDwKdBmwjL5l YunY2c4w2mKvnHKaeXydbbeVoKGpDMnOJkHXAO0DiCKHDbuEIuuFJasNNdI3UDf2 6rDBAMW8c1lStTYaMRbQ =1i7n -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 engineering manager
On Thu, Oct 31, 2013 at 09:47:36PM -0500, Dennis Gilmore wrote: El Thu, 31 Oct 2013 22:42:52 -0400 Paul W. Frields sticks...@gmail.com escribió: Hi Fedora folks, Hopefully some of you know me, possibly as a previous Fedora Project Leader at Red Hat. If you don't, then salutations, and please feel free to check out my Fedora wiki page[1] for my background. :-) As of next Monday, I'll be the reporting manager for Fedora Engineering team members -- those folks who work on Fedora full time in the Engineering department of Red Hat, other than the Fedora Project Leader, Robyn Bergeron. This doesn't really affect anything in the community, but I want to ensure that change is transparent to the community. Just so its clear, I think I'm the only other person who works full time on Fedora at Red Hat, but I'm in a different part of the organisation and have a different reporting structure. Oops! You know, it would be easier if I just list the people that will be reporting to me as of Monday: Ralph Bean Aurelien Bompard Josh Boyer Pierre Chibon Mo Duffy Ricky Elrod Kevin Fenzi Justin Forbes Dave Jones Toshio Kuratomi Ryan Lerch Luke Macken Stephen Smoogen Ian Weller -- Paul W. Frieldshttp://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 http://redhat.com/ - - - - http://pfrields.fedorapeople.org/ The open source story continues to grow: http://opensource.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
Re: Fedora search
On Wed, 30 Oct, 2013 at 19:29:25 GMT, Michael Cronenworth wrote: What about using a custom Google search engine? https://www.google.com/cse/ Google is having more and more privacy issues lately. Why not use DuckDuckGo and write a 'bang' search for fedora sites? !fedora-guidelines, !fedora-package !fedora-wiki, etc.? --Ben -- 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: openssl multilib broken
Reindl Harald wrote:
but sadly you can't do Requires: package.x86_64 explicitly
You can actually:
Requires: openssl(x86-64)
See also the %{_isa} macro.
http://www.rpm.org/wiki/PackagerDocs/ArchDependencies
(This is also what Michael Schwendt's repoquery invocation in this thread
checked for.)
Requires: openssl catched both
And to fix this broken behavior, set exactarch=1 in yum.conf. This is the
default for fresh installs of current versions of Fedora, but some old
releases defaulted to exactarch=0.
Kevin Kofler
--
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: Is Gnome Software ready for primetime ?
Matthias Clasen wrote: On Thu, 2013-10-31 at 14:31 +0100, Tim Lauridsen wrote: Look at System - File Tools - Caja-actions configuration tool Get the cinnamon guys to fork the nautilus appdata ? I'm sure it will only need minor adjustments... :-) Caja is actually from MATE, Cinnamon has Nemo. Kevin Kofler -- 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: Is Gnome Software ready for primetime ?
Matthias Clasen wrote: It is an application installer, first and foremost. Installing backgrounds/icons/themes is not a priority. Having as the only GUI package management application on your spin one that does not even offer all packages is very broken. We have a notion of 'core app' - for things that 'come with the OS'. We don't allow to uninstall those. WTF!? Compared to Ubuntu, certainly. But compared to gpk-application F19, I don't think so. Always the same broken assumption that Ubuntu's flawed design is the model to copy. Kevin Kofler -- 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: 20131026 changes
Fedora Rawhide Report wrote: New package: lpf-0-8.ff50a5b.fc21 Local package factory - build non-redistributable rpms New package: lpf-spotify-client-0.9.4.183.g644e24e.428-2.fc21 Spotify music player native client package bootstrap WTF??? https://fedorahosted.org/fpc/ticket/362 Kevin Kofler -- 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: Is Gnome Software ready for primetime ?
On Thu, 2013-10-31 at 14:31 +0100, Tim Lauridsen wrote: I know Richard has pushed hard to get appdata for apps, but it do help the end user, if lot of apps in gnome-software dont have any descriptions. Look at System - File Tools - Caja-actions configuration tool How should an end user have a clue what this app does ? This really does require package maintainers to pay attention and include appdata files for their packages. I've done quite a few, for packages that I maintain and ones that I use. However, sending appdata files upstream requires new bugtracker accounts and since existing package maintainers are supposed to have these already, it's really best if they write up and include appstream data, or at least take submissions from the community and send them upstream. I've requested a list of packages missing appdata[1]. Once I have that, I'll go ahead and file bugs in the hope that it'll get maintainers to take out the five minutes required to write and submit these. [1] https://github.com/hughsie/fedora-appstream/issues/13 -- 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 Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora Working Groups: Call for Self-Nominations
Bill Nottingham wrote: And I would argue that having the user interface swing wildly in design implementation based on the current composition of an elected board that is refreshed in part every six months is not the sort of situation that Fedora would want to be in anyway. That's a very lame excuse for sticking with an awful desktop environment as the default just because it is the status quo. Kevin Kofler -- 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: Is Gnome Software ready for primetime ?
On Fri, 2013-11-01 at 04:19 +0100, Kevin Kofler wrote: Having as the only GUI package management application on your spin one that does not even offer all packages is very broken. It isn't a *package* management application. It's an *application* management application, ie., it only handles packages that are desktop applications (and therefore have desktop files associated with them). I'm guessing power users that want to install other packages will need to resort to the command line: yum/dnf/packagekit-cli. I'm not really sure about this though. Someone else might know better. http://fedoraproject.org/wiki/Changes/AppInstaller -- 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 Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora search
On Fri, Nov 1, 2013 at 3:05 AM, Ben Boeckel maths...@gmail.com wrote: On Wed, 30 Oct, 2013 at 19:29:25 GMT, Michael Cronenworth wrote: What about using a custom Google search engine? https://www.google.com/cse/ Google is having more and more privacy issues lately. Why not use DuckDuckGo and write a 'bang' search for fedora sites? !fedora-guidelines, !fedora-package !fedora-wiki, etc.? I think this goes back to the concept of having something that we can do for ourselves. Something that we can take in and manage on our own. Sure, at first it will be a lot of heavy lifting but this is not something I mind. It has to be done. I think we really just need to look into tools that are free and open source and then move forward. However, as mentioned before this is my opinion. The more criticised the better. If we(the community at large) do not mind, can we proceed to look at various tools. Thanks . --Ben -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- Skype: Frankie.Onuonga twitter: Frankieonuonga irc #freenode: Frankie.onuonga -- 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: Is Gnome Software ready for primetime ?
On Fri, Nov 1, 2013 at 4:58 AM, Ankur Sinha sanjay.an...@gmail.com wrote: It isn't a *package* management application. It's an *application* management application, ie., it only handles packages that are desktop applications (and therefore have desktop files associated with them). I'm guessing power users that want to install other packages will need to resort to the command line: yum/dnf/packagekit-cli. I'm not really sure about this though. Someone else might know better. All users can use yumex, if they want a package management gui, there can install every thing they want but it is not installed by default in the Gnome desktop, so new user need to find out how to install it or how to to use yum from the command line. Tim -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
File DateTime-Format-DBI-0.041.tar.gz uploaded to lookaside cache by psabata
A file has been added to the lookaside cache for perl-DateTime-Format-DBI: 135955e52b3a3083ec3b4e0d7bd4de5d DateTime-Format-DBI-0.041.tar.gz -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
File ctstream-9 uploaded to lookaside cache by ppisar
A file has been added to the lookaside cache for ctstream: 7949c8947140894ceb656fc413d00fec ctstream-9 -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[ctstream] Version 9 bump
commit 4aa0fbc6827b0b85bcb52895c1440656466f867f
Author: Petr Písař ppi...@redhat.com
Date: Thu Oct 31 07:49:24 2013 +0100
Version 9 bump
.gitignore|1 +
ctstream.spec |7 +--
sources |2 +-
3 files changed, 7 insertions(+), 3 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index 8c6b7ee..ae98988 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1,3 +1,4 @@
/ctstream-6
/ctstream-7
/ctstream-8
+/ctstream-9
diff --git a/ctstream.spec b/ctstream.spec
index ed9620d..f576723 100644
--- a/ctstream.spec
+++ b/ctstream.spec
@@ -1,6 +1,6 @@
Name: ctstream
-Version:8
-Release:3%{?dist}
+Version:9
+Release:1%{?dist}
Summary:Get URLs of Czech Television video streams
Group: Applications/Internet
License:GPL+
@@ -23,6 +23,9 @@ install %{SOURCE0} %{buildroot}%{_bindir}/%{name}
%{_bindir}/*
%changelog
+* Thu Oct 31 2013 Petr Pisar ppi...@redhat.com - 9-1
+- Version 9 bump
+
* Sat Aug 03 2013 Fedora Release Engineering rel-...@lists.fedoraproject.org
- 8-3
- Rebuilt for https://fedoraproject.org/wiki/Fedora_20_Mass_Rebuild
diff --git a/sources b/sources
index a27e3dc..2ee8dd8 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-75f8d6545be37d2b358be02e76657758 ctstream-8
+7949c8947140894ceb656fc413d00fec ctstream-9
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 1024821] ctstream-9 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1024821 --- Comment #1 from Petr Pisar ppi...@redhat.com --- This is a bug-fix release suitable for all Fedoras. -- 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=jp0CSgYyZHa=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-DateTime-Format-DBI] 0.041 bump
commit 6f6050eecfbed9396b44530d87644b635f92f112
Author: Petr Šabata con...@redhat.com
Date: Thu Oct 31 15:49:59 2013 +0900
0.041 bump
.gitignore|1 +
perl-DateTime-Format-DBI.spec | 32 ++--
sources |2 +-
3 files changed, 20 insertions(+), 15 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index 5307888..7584e81 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1,2 +1,3 @@
DateTime-Format-DBI-0.032.tar.gz
/DateTime-Format-DBI-0.040.tar.gz
+/DateTime-Format-DBI-0.041.tar.gz
diff --git a/perl-DateTime-Format-DBI.spec b/perl-DateTime-Format-DBI.spec
index 1a6d375..4200e74 100644
--- a/perl-DateTime-Format-DBI.spec
+++ b/perl-DateTime-Format-DBI.spec
@@ -1,22 +1,26 @@
Name: perl-DateTime-Format-DBI
-Version:0.040
-Release:8%{?dist}
+Version:0.041
+Release:1%{?dist}
Summary:Find a parser class for a database connection
License:GPL+ or Artistic
Group: Development/Libraries
URL:http://search.cpan.org/dist/DateTime-Format-DBI/
Source0:
http://www.cpan.org/authors/id/C/CF/CFAERBER/DateTime-Format-DBI-%{version}.tar.gz
BuildArch: noarch
-Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo
$version))
+Requires: perl(:MODULE_COMPAT_%(eval $(perl -V:version); echo
$version))
+BuildRequires: iconv
+BuildRequires: perl
BuildRequires: perl(Carp)
BuildRequires: perl(DateTime) = 0.1
BuildRequires: perl(DateTime::Format::SQLite)
BuildRequires: perl(DBD::SQLite)
BuildRequires: perl(DBI) = 1.21
BuildRequires: perl(ExtUtils::MakeMaker)
-BuildRequires: perl(Test::Database)
+BuildRequires: perl(strict)
BuildRequires: perl(Test::More)
BuildRequires: perl(Test::NoWarnings)
+BuildRequires: perl(vars)
+BuildRequires: perl(warnings)
# require the dbd-specific datetime formats, so this just works the way we
# expect it to.
Requires: perl(DateTime::Format::MySQL)
@@ -33,31 +37,31 @@ perl-DateTime-MySQL, perl-DateTime-Oracle,
perl-DateTime-DB2, etc.
%prep
%setup -q -n DateTime-Format-DBI-%{version}
-for i in LICENSE README lib/DateTime/Format/DBI.pm ; do
-# correct UTF-8 wonkiness
-cat $i | iconv -f ISO-8859-1 -t UTF-8 foo
-mv foo $i
-done
+iconv -f ISO-8859-1 -t UTF-8 LICENSE LICENSE.utf \
+touch -r LICENSE LICENSE.utf \
+mv -f LICENSE.utf LICENSE
%build
-%{__perl} Makefile.PL INSTALLDIRS=vendor
+perl Makefile.PL INSTALLDIRS=vendor
make %{?_smp_mflags}
%install
-make pure_install PERL_INSTALL_ROOT=%{buildroot}
-find %{buildroot} -type f -name .packlist -exec rm -f {} \;
-find %{buildroot} -depth -type d -exec rmdir {} 2/dev/null \;
+make pure_install DESTDIR=%{buildroot}
+find %{buildroot} -type f -name .packlist -exec rm -f {} +
%{_fixperms} %{buildroot}/*
%check
make test
%files
-%doc Changes LICENSE README t/
+%doc Changes LICENSE README
%{perl_vendorlib}/*
%{_mandir}/man3/*
%changelog
+* Thu Oct 31 2013 Petr Šabata con...@redhat.com - 0.041-1
+- 0.041 bump
+
* Sat Aug 03 2013 Fedora Release Engineering rel-...@lists.fedoraproject.org
- 0.040-8
- Rebuilt for https://fedoraproject.org/wiki/Fedora_20_Mass_Rebuild
diff --git a/sources b/sources
index f9e81ea..d93bcca 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-5f18a034988a37035bdf0c99e583f54a DateTime-Format-DBI-0.040.tar.gz
+135955e52b3a3083ec3b4e0d7bd4de5d DateTime-Format-DBI-0.041.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[ctstream/f20] Version 9 bump
Summary of changes: 4aa0fbc... Version 9 bump (*) (*) 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-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[ctstream/f19] Version 9 bump
commit a389770d5012aa0640d674801e138509cee834ee
Author: Petr Písař ppi...@redhat.com
Date: Thu Oct 31 07:49:24 2013 +0100
Version 9 bump
.gitignore|1 +
ctstream.spec |5 -
sources |2 +-
3 files changed, 6 insertions(+), 2 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index 8c6b7ee..ae98988 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1,3 +1,4 @@
/ctstream-6
/ctstream-7
/ctstream-8
+/ctstream-9
diff --git a/ctstream.spec b/ctstream.spec
index 91afa21..b725613 100644
--- a/ctstream.spec
+++ b/ctstream.spec
@@ -1,5 +1,5 @@
Name: ctstream
-Version:8
+Version:9
Release:1%{?dist}
Summary:Get URLs of Czech Television video streams
Group: Applications/Internet
@@ -23,6 +23,9 @@ install %{SOURCE0} %{buildroot}%{_bindir}/%{name}
%{_bindir}/*
%changelog
+* Thu Oct 31 2013 Petr Pisar ppi...@redhat.com - 9-1
+- Version 9 bump
+
* Mon May 27 2013 Petr Pisar ppi...@redhat.com - 8-1
- Version 8 bump
diff --git a/sources b/sources
index a27e3dc..2ee8dd8 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-75f8d6545be37d2b358be02e76657758 ctstream-8
+7949c8947140894ceb656fc413d00fec ctstream-9
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 1022676] perl-DateTime-Format-DBI-0.041 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1022676 Petr Šabata psab...@redhat.com changed: What|Removed |Added Status|ASSIGNED|CLOSED Fixed In Version||perl-DateTime-Format-DBI-0. ||041-1.fc21 Resolution|--- |RAWHIDE Last Closed||2013-10-31 02:52:46 -- 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=dCqkYVqZofa=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[ctstream/f18] Version 9 bump
commit 65d8f35de06fd0ebf331b5bd5d6cbd2b7d19ac2c
Author: Petr Písař ppi...@redhat.com
Date: Thu Oct 31 07:49:24 2013 +0100
Version 9 bump
.gitignore|1 +
ctstream.spec |5 -
sources |2 +-
3 files changed, 6 insertions(+), 2 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index 8c6b7ee..ae98988 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1,3 +1,4 @@
/ctstream-6
/ctstream-7
/ctstream-8
+/ctstream-9
diff --git a/ctstream.spec b/ctstream.spec
index 9f3693b..8850b0e 100644
--- a/ctstream.spec
+++ b/ctstream.spec
@@ -1,5 +1,5 @@
Name: ctstream
-Version:8
+Version:9
Release:1%{?dist}
Summary:Get URLs of Czech Television video streams
Group: Applications/Internet
@@ -23,6 +23,9 @@ install %{SOURCE0} %{buildroot}%{_bindir}/%{name}
%{_bindir}/*
%changelog
+* Thu Oct 31 2013 Petr Pisar ppi...@redhat.com - 9-1
+- Version 9 bump
+
* Mon May 27 2013 Petr Pisar ppi...@redhat.com - 8-1
- Version 8 bump
diff --git a/sources b/sources
index a27e3dc..2ee8dd8 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-75f8d6545be37d2b358be02e76657758 ctstream-8
+7949c8947140894ceb656fc413d00fec ctstream-9
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 1024821] ctstream-9 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1024821 Petr Pisar ppi...@redhat.com changed: What|Removed |Added Status|ASSIGNED|MODIFIED Fixed In Version||ctstream-9-1.fc21 -- 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=ZUnj8FziS5a=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 1024821] ctstream-9 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1024821 --- Comment #2 from Fedora Update System upda...@fedoraproject.org --- ctstream-9-1.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/ctstream-9-1.fc20 -- 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=eVk0ql6xs2a=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 1024821] ctstream-9 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1024821 --- Comment #3 from Fedora Update System upda...@fedoraproject.org --- ctstream-9-1.fc19 has been submitted as an update for Fedora 19. https://admin.fedoraproject.org/updates/ctstream-9-1.fc19 -- 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=UNKvD9WEBaa=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 1024821] ctstream-9 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1024821 --- Comment #4 from Fedora Update System upda...@fedoraproject.org --- ctstream-9-1.fc18 has been submitted as an update for Fedora 18. https://admin.fedoraproject.org/updates/ctstream-9-1.fc18 -- 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=YSMDyhjBHxa=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 1022682] perl-X11-Protocol-Other-27 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1022682 Upstream Release Monitoring upstream-release-monitor...@fedoraproject.org changed: What|Removed |Added Summary|perl-X11-Protocol-Other-26 |perl-X11-Protocol-Other-27 |is available|is available --- Comment #1 from Upstream Release Monitoring upstream-release-monitor...@fedoraproject.org --- Latest upstream release: 27 Current version/release in Fedora Rawhide: 25-1.fc21 URL: http://search.cpan.org/dist/X11-Protocol-Other/ 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=T7OjDGC2cda=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
File Perl-Critic-Deprecated-1.119.tar.gz uploaded to lookaside cache by ppisar
A file has been added to the lookaside cache for perl-Perl-Critic-Deprecated: fe789d45277b769a244da8d3b5f7b00b Perl-Critic-Deprecated-1.119.tar.gz -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Perl-Critic-Deprecated] 1.119 bump
commit 3fa6a778ad9e5559a85a44df470a555a9955fb82
Author: Petr Písař ppi...@redhat.com
Date: Thu Oct 31 08:31:01 2013 +0100
1.119 bump
.gitignore |1 +
perl-Perl-Critic-Deprecated.spec |7 +--
sources |2 +-
3 files changed, 7 insertions(+), 3 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index 1de8f0e..cfd0b03 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1,2 +1,3 @@
/Perl-Critic-Deprecated-1.108.tar.gz
/Perl-Critic-Deprecated-1.118.tar.gz
+/Perl-Critic-Deprecated-1.119.tar.gz
diff --git a/perl-Perl-Critic-Deprecated.spec b/perl-Perl-Critic-Deprecated.spec
index 77332a1..8ff64e8 100644
--- a/perl-Perl-Critic-Deprecated.spec
+++ b/perl-Perl-Critic-Deprecated.spec
@@ -1,5 +1,5 @@
Name: perl-Perl-Critic-Deprecated
-Version:1.118
+Version:1.119
Release:1%{?dist}
Summary:Perl::Critic policies which have been superseded by others
License:GPL+ or Artistic
@@ -41,7 +41,7 @@ Conflicts: perl-Perl-Critic-More = 1.000-11
The included policies are:
- Write $my_variable = 42 instead of $MyVariable = 42.
- Write sub my_function{} instead of sub MyFunction{}.
- - Write RCS keywords like $Revision: 42 $ into source files.
+ - Put source-control keywords in every file.
%prep
%setup -q -n Perl-Critic-Deprecated-%{version}
@@ -63,6 +63,9 @@ perl Build.PL installdirs=vendor
%{_mandir}/man3/*
%changelog
+* Thu Oct 31 2013 Petr Pisar ppi...@redhat.com - 1.119-1
+- 1.119 bump
+
* Tue Oct 29 2013 Petr Pisar ppi...@redhat.com - 1.118-1
- 1.118 bump
diff --git a/sources b/sources
index 05b6c9e..14ceb77 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-1b7fc22927e26ec338f28be46c639358 Perl-Critic-Deprecated-1.118.tar.gz
+fe789d45277b769a244da8d3b5f7b00b Perl-Critic-Deprecated-1.119.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-DateTime-Format-DBI] Correct iconv BR
commit 852d9874d3c579540750ff402c048fd7b021a000
Author: Petr Šabata con...@redhat.com
Date: Thu Oct 31 16:32:45 2013 +0900
Correct iconv BR
perl-DateTime-Format-DBI.spec |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
---
diff --git a/perl-DateTime-Format-DBI.spec b/perl-DateTime-Format-DBI.spec
index 4200e74..de2934f 100644
--- a/perl-DateTime-Format-DBI.spec
+++ b/perl-DateTime-Format-DBI.spec
@@ -8,7 +8,7 @@ URL:http://search.cpan.org/dist/DateTime-Format-DBI/
Source0:
http://www.cpan.org/authors/id/C/CF/CFAERBER/DateTime-Format-DBI-%{version}.tar.gz
BuildArch: noarch
Requires: perl(:MODULE_COMPAT_%(eval $(perl -V:version); echo
$version))
-BuildRequires: iconv
+BuildRequires: %{_bindir}/iconv
BuildRequires: perl
BuildRequires: perl(Carp)
BuildRequires: perl(DateTime) = 0.1
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
File Perl-Critic-More-1.003.tar.gz uploaded to lookaside cache by ppisar
A file has been added to the lookaside cache for perl-Perl-Critic-More: 00deaf3d49835ae12f59ccd2fcea9045 Perl-Critic-More-1.003.tar.gz -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Perl-Critic-More] Remove unneeded Perl-Critic-More-1.000-Miscellanea::RequireRcsKeywords.patch
commit c2f8861e72e7a722bcbba8727adb33d8e7dfed3a Author: Petr Písař ppi...@redhat.com Date: Thu Oct 31 08:33:55 2013 +0100 Remove unneeded Perl-Critic-More-1.000-Miscellanea::RequireRcsKeywords.patch ...ore-1.000-Miscellanea::RequireRcsKeywords.patch | 236 1 files changed, 0 insertions(+), 236 deletions(-) -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Perl-Critic-More] 1.003 bump
commit 852a5ef3d669041f8b75eb67fca423f1c77b5489
Author: Petr Písař ppi...@redhat.com
Date: Thu Oct 31 08:37:01 2013 +0100
1.003 bump
.gitignore |1 +
perl-Perl-Critic-More.spec |5 -
sources|2 +-
3 files changed, 6 insertions(+), 2 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index 70493a0..c57b4ae 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1,2 +1,3 @@
/Perl-Critic-More-1.000.tar.gz
/Perl-Critic-More-1.002.tar.gz
+/Perl-Critic-More-1.003.tar.gz
diff --git a/perl-Perl-Critic-More.spec b/perl-Perl-Critic-More.spec
index f069043..8044127 100644
--- a/perl-Perl-Critic-More.spec
+++ b/perl-Perl-Critic-More.spec
@@ -1,5 +1,5 @@
Name: perl-Perl-Critic-More
-Version:1.002
+Version:1.003
Release:1%{?dist}
Summary:Supplemental policies for Perl::Critic
License:GPL+ or Artistic
@@ -64,6 +64,9 @@ perl Build.PL installdirs=vendor
%{_mandir}/man3/*
%changelog
+* Thu Oct 31 2013 Petr Pisar ppi...@redhat.com - 1.003-1
+- 1.003 bump
+
* Tue Oct 29 2013 Petr Pisar ppi...@redhat.com - 1.002-1
- 1.002 bump
diff --git a/sources b/sources
index c772e0b..f9290b9 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-dc652a42d54ea69d700582b6cbf10163 Perl-Critic-More-1.002.tar.gz
+00deaf3d49835ae12f59ccd2fcea9045 Perl-Critic-More-1.003.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 1024894] perl-Perl-Critic-Deprecated-1.119 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1024894 Petr Pisar ppi...@redhat.com changed: What|Removed |Added Status|ASSIGNED|CLOSED Fixed In Version||perl-Perl-Critic-Deprecated ||-1.119-1.fc21 Resolution|--- |RAWHIDE Last Closed||2013-10-31 03:41:27 -- 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=6r7Gp3Tj8pa=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 1024896] perl-Perl-Critic-More-1.003 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1024896 Petr Pisar ppi...@redhat.com changed: What|Removed |Added Status|ASSIGNED|CLOSED Fixed In Version||perl-Perl-Critic-More-1.003 ||-1.fc21 Resolution|--- |RAWHIDE Last Closed||2013-10-31 03:46:11 -- 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=GhJG5q98bwa=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
File Authen-Radius-0.23.tar.gz uploaded to lookaside cache by pghmcfc
A file has been added to the lookaside cache for perl-Authen-Radius: 556c5bea85f67ab83ec247a74c65e27e Authen-Radius-0.23.tar.gz -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
