EPEL Fedora 6 updates-testing report
The following Fedora EPEL 6 Security updates need testing: Age URL 508 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2012-5620/bugzilla-3.4.14-2.el6 27 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2013-11198/filezilla-3.7.3-1.el6 22 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2013-11274/ssmtp-2.61-21.el6 11 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2013-11393/nagios-3.5.1-1.el6 9 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2013-11417/graphite-web-0.9.12-1.el6 7 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2013-11445/perl-Crypt-DSA-1.17-10.el6 6 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2013-11453/python-pyrad-2.0-3.el6 3 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2013-11499/roundcubemail-0.9.4-1.el6 1 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2013-11507/tinyproxy-1.8.3-1.el6 0 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2013-11525/moodle-2.4.6-1.el6 0 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2013-11556/openstack-swift-1.7.4-3.el6 0 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2013-11550/Django14-1.4.7-1.el6 0 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2013-11552/glpi-0.83.9.1-4.el6 The following builds have been pushed to Fedora EPEL 6 updates-testing Django14-1.4.7-1.el6 glpi-0.83.9.1-4.el6 ldapvi-1.7-17.el6 nf3d-0.8-1.el6 openstack-swift-1.7.4-3.el6 openvpn-2.3.2-2.el6 perl-File-KeePass-2.03-3.el6 php-htmLawed-1.1.16-1.el6 qt5-qtgraphicaleffects-5.1.1-1.el6 qt5-qtimageformats-5.1.1-1.el6 qt5-qtsvg-5.1.1-1.el6 qt5-qttools-5.1.1-3.el6 qt5-qtwebkit-5.1.1-1.el6 qt5-qtxmlpatterns-5.1.1-1.el6 qtbrowserplugin-2.4-3.el6 racoon2-20100526a-23.el6 wcd-5.2.4-1.el6 Details about builds: Django14-1.4.7-1.el6 (FEDORA-EPEL-2013-11550) A high-level Python Web framework Update Information: Rebase to 1.4.7, fixes CVE-2013-4315 ChangeLog: * Thu Sep 12 2013 Matthias Runge mru...@redhat.com - 1.4.7-1 - update to 1.4.7, fix CVE 2013-4315, fixes rhbz 1007020 References: [ 1 ] Bug #1004969 - CVE-2013-4315 python-django: directory traversal with ssi template tag https://bugzilla.redhat.com/show_bug.cgi?id=1004969 glpi-0.83.9.1-4.el6 (FEDORA-EPEL-2013-11552) Free IT asset management software Update Information: Security improvement: restrict access to installation wizard from local server only. Remote access need to be explicitly allowed in configuration (/etc/httpd/conf.d/glpi.conf). ChangeLog: * Thu Sep 12 2013 Remi Collet r...@fedoraproject.org - 0.83.9.1-4 - restrict access for install to local for security - drop bundled Flash files files, #1000251 - Add a missing requirement on crontabs to spec file ldapvi-1.7-17.el6 (FEDORA-EPEL-2013-11546) An interactive LDAP client Update Information: Add fix of double free() crash (#949157), also fix old FSF address ChangeLog: * Wed Sep 11 2013 Matěj Cepl mc...@redhat.com - 1.7-17 - Add fix of double free() crash (#949157) - Fix old FSF address * Sat Aug 3 2013 Fedora Release Engineering rel-...@lists.fedoraproject.org - 1.7-16 - Rebuilt for https://fedoraproject.org/wiki/Fedora_20_Mass_Rebuild * Thu Feb 14 2013 Fedora Release Engineering rel-...@lists.fedoraproject.org - 1.7-15 - Rebuilt for https://fedoraproject.org/wiki/Fedora_19_Mass_Rebuild * Thu Jul 19 2012 Fedora Release Engineering rel-...@lists.fedoraproject.org - 1.7-14 - Rebuilt for https://fedoraproject.org/wiki/Fedora_18_Mass_Rebuild * Fri Jan 13 2012 Fedora Release Engineering rel-...@lists.fedoraproject.org - 1.7-13 - Rebuilt for https://fedoraproject.org/wiki/Fedora_17_Mass_Rebuild References: [ 1 ] Bug #949157 - [PATCH] fix use-after-free in sasl code https://bugzilla.redhat.com/show_bug.cgi?id=949157
Re: Firewall blocking desktop features
Application should request the ports to be opened and the firewalld layer should then confirm with the user stating which ports and which app requested said ports. The app can't lie if the firewall layer is the one asking for confirmation. But a malicious app can pretend to be another one, unless there is a way for the firewall to know which app is asking in a way that cannot be forged. Pierre -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Firewall blocking desktop features
On Thursday 12 September 2013 08:25:21 Pierre-Yves Chibon wrote: Application should request the ports to be opened and the firewalld layer should then confirm with the user stating which ports and which app requested said ports. The app can't lie if the firewall layer is the one asking for confirmation. But a malicious app can pretend to be another one, unless there is a way for the firewall to know which app is asking in a way that cannot be forged. But there is a way: * The firewall management software (firewalld?) would listen over a local stream socket. * The requesting application would connect to this socket with SO_PASSCRED and send its request for ports. * The firewall management software would ignore (and log) connections without SCM_CREDENTIALS. * with SCM_CREDETIALS you have uid, gid and pid of the caller. * From pid you can find the real executable (/proc/pid/cmd). Oh, and btw, when the client closes the connection (e.g: when it terminates) we should close the requested ports so we don't leave unused ports open for future malicious apps. -- Oron Peled Voice: +972-4-8228492 o...@actcom.co.il http://users.actcom.co.il/~oron Simplicity is prerequisite for reliability. -- Edsger Wybe Dijkstra -- 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: F20 KDE session login options
On Thu, 12 Sep 2013 02:17:48 +0200, Michael Catanzaro mike.catanz...@gmail.com wrote: On Thu, 2013-09-12 at 00:13 +0100, Ian Malone wrote: 1. This is the case for the KDE live CD install too. 2. Where the custom session might be coming from (wondering if something specific to this spin or the KDE spins in gene It comes from SDDM directly. Looks like https://bugzilla.redhat.com/show_bug.cgi?id=1004902 Exactly, thank you. -- 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: F20 KDE session login options
I had same issue after I installed it 15 days ago. I should test sddm before approved it... CC now. -- 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: Summary/Minutes from today's FESCo Meeting (2013-09-11)
On 09/12/2013 02:10 AM, Matthew Miller wrote: This was convered in the proposal, and that's why there was a bug already filed to change the agetty command line ingetty@.service. But now Jóhann has now closed them all as WONTFIX so I'm not sure what's going on. I sought after fixing a problem but due to real estate investment from FESCO they elected not fixing it ( you know the classic vote on my personal feelings rather then practicality ), thus not solving the problem I was actually trying to fix hence closing all bugs with all the patches. JBG -- 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: Oracle considering DB6 license
On 09/12/2013 07:16 AM, Jan Staněk wrote: Hello, some time back Oracle released new version of Berkeley DB under AGPL, which is incompatible with Fedora licensing politics. However, https://forums.oracle.com/message/11184885#11184885 If you are interested in DB6, consider leaving feedback there :) Week later... it turns out that Oracle might consider re-licensing it back :) JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Heads up! I'm going to upgrade Wireshark up to 1.10.x in Fedora 18
Hello All! There are *lots* of CVEs against Wireshark shipped with Fedora 18 (quite old 1.8.8 version). * https://bugzilla.redhat.com/965942 * https://bugzilla.redhat.com/972762 * https://bugzilla.redhat.com/990189 In order to fix them and not to add additional work for the maintainers I'm thinking of upgrading up to 1.10.2 from 1.8.x. Instead of backporting stuff let's build the latest stable! I'm sure users will love this, since new Wireshark adds a lot of new features and fixes all these CVEs. -- With best regards, Peter Lemenkov. -- 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: Heads up! I'm going to upgrade Wireshark up to 1.10.x in Fedora 18
Hi Peter, On 09/12/2013 10:00 AM, Peter Lemenkov wrote: Hello All! There are *lots* of CVEs against Wireshark shipped with Fedora 18 (quite old 1.8.8 version). * https://bugzilla.redhat.com/965942 * https://bugzilla.redhat.com/972762 * https://bugzilla.redhat.com/990189 In order to fix them and not to add additional work for the maintainers I'm thinking of upgrading up to 1.10.2 from 1.8.x. Well, idea looks fine, but before pushing such update, give us some time to reply to your message (3 minutes is not enough). Instead of backporting stuff let's build the latest stable! I'm sure users will love this, since new Wireshark adds a lot of new features and fixes all these CVEs. I would rather stick to 1.8.10, which is the latest Maintenance release of wireshark. 1.8.10 will be certainly more OK with Fedora Update Policy [1] [2] [3]. I don't think, Wireshark is on exception list. [1] http://fedoraproject.org/wiki/Updates_Policy#Stable_Releases [2] http://fedoraproject.org/wiki/Updates_Policy#Philosophy [3] Have a nice day :) -- Peter Hatina ENG Server Experience, System Management Red Hat Czech, Brno -- 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: Heads up! I'm going to upgrade Wireshark up to 1.10.x in Fedora 18
On 09/12/2013 10:17 AM, Peter Hatina wrote: Hi Peter, On 09/12/2013 10:00 AM, Peter Lemenkov wrote: Hello All! There are *lots* of CVEs against Wireshark shipped with Fedora 18 (quite old 1.8.8 version). * https://bugzilla.redhat.com/965942 * https://bugzilla.redhat.com/972762 * https://bugzilla.redhat.com/990189 In order to fix them and not to add additional work for the maintainers I'm thinking of upgrading up to 1.10.2 from 1.8.x. Well, idea looks fine, but before pushing such update, give us some time to reply to your message (3 minutes is not enough). Instead of backporting stuff let's build the latest stable! I'm sure users will love this, since new Wireshark adds a lot of new features and fixes all these CVEs. I would rather stick to 1.8.10, which is the latest Maintenance release of wireshark. 1.8.10 will be certainly more OK with Fedora Update Policy [1] [2] [3]. I don't think, Wireshark is on exception list. [1] http://fedoraproject.org/wiki/Updates_Policy#Stable_Releases [2] http://fedoraproject.org/wiki/Updates_Policy#Philosophy [3] Have a nice day :) Ah, link 3 is missing. [3] http://fedoraproject.org/wiki/Updates_Policy#All_other_updates [4] http://fedoraproject.org/wiki/Updates_Policy#Exceptions Cheers -- Peter Hatina ENG Server Experience, System Management Red Hat Czech, Brno -- 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: Heads up! I'm going to upgrade Wireshark up to 1.10.x in Fedora 18
2013/9/12 Peter Hatina phat...@redhat.com: Hi Peter, On 09/12/2013 10:00 AM, Peter Lemenkov wrote: Hello All! There are *lots* of CVEs against Wireshark shipped with Fedora 18 (quite old 1.8.8 version). * https://bugzilla.redhat.com/965942 * https://bugzilla.redhat.com/972762 * https://bugzilla.redhat.com/990189 In order to fix them and not to add additional work for the maintainers I'm thinking of upgrading up to 1.10.2 from 1.8.x. Well, idea looks fine, but before pushing such update, give us some time to reply to your message (3 minutes is not enough). Instead of backporting stuff let's build the latest stable! I'm sure users will love this, since new Wireshark adds a lot of new features and fixes all these CVEs. I would rather stick to 1.8.10, which is the latest Maintenance release of wireshark. 1.8.10 will be certainly more OK with Fedora Update Policy [1] [2] [3]. I don't think, Wireshark is on exception list. I'm afraid that's just adds additional work for maintainers w/o any visible benefits. Let's move further instead of backporting - that's just a leafnode app so nobody got hurt by a potential dependency issue. Regarding version - fortunately that's not a critpath application, so we have a lot of freedom here. -- With best regards, Peter Lemenkov. -- 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 Alpha Release Candidate 2 (RC2) Available Now!
NOTE: The 32- and 64-bit DVDs, the 64-bit Desktop Live, the 32-bit MATE and Security Spins, and the 64-bit LXDE and MATE Spins are over their respective size targets. As per the Fedora 20 schedule [1], Fedora 20 Alpha Release Candidate 2 (RC2) is now available for testing. Content information, including changes, can be found at https://fedorahosted.org/rel-eng/ticket/5745#comment:26 . Please see the following pages for download links (including delta ISOs) and testing instructions. Normally dl.fedoraproject.org should provide the fastest download, but download-ib01.fedoraproject.org is available as a mirror (with an approximately 1 hour lag) in case of trouble. To use it, just replace dl with download-ib01 in the download URL. Installation: https://fedoraproject.org/wiki/Test_Results:Current_Installation_Test Base: https://fedoraproject.org/wiki/Test_Results:Current_Base_Test Desktop: https://fedoraproject.org/wiki/Test_Results:Current_Desktop_Test Ideally, all Alpha priority test cases for Installation [2], Base [3], and Desktop [4] should pass in order to meet the Alpha Release Criteria [5]. Help is available on #fedora-qa on irc.freenode.net [6], or on the test list [7]. Create Fedora 20 Alpha test compose (TC) and release candidate (RC) https://fedorahosted.org/rel-eng/ticket/5745 Current Blocker and Freeze Exception bugs: http://qa.fedoraproject.org/blockerbugs/current [1] http://fedorapeople.org/groups/schedule/f-20/f-20-quality-tasks.html [2] https://fedoraproject.org/wiki/QA:Installation_validation_testing [3] https://fedoraproject.org/wiki/QA:Base_validation_testing [4] https://fedoraproject.org/wiki/QA:Desktop_validation_testing [5] https://fedoraproject.org/wiki/Fedora_20_Alpha_Release_Criteria [6] irc://irc.freenode.net/fedora-qa [7] https://admin.fedoraproject.org/mailman/listinfo/test signature.asc Description: OpenPGP digital signature ___ 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
Re: Merging freediams into freemedforms
Hi Michael, I'm sorry for the *very* delayed reply. I hadn't noticed this mail come in. On Sun, 2013-08-18 at 20:41 +0200, Michael Schwendt wrote: On Sat, 17 Aug 2013 23:05:48 +1000, Ankur Sinha wrote: Hi, I maintain two packages for the fedora-medical SIG that fall under the freemedforms[1] project. At the moment, these are packaged separately: 1. freemedforms[2]: provides freemedforms-emr and pulls in freediams 2. freediams[3] Now, freemedforms-emr and freediams are both built from the same source, Since Fedora package git has been changed already, I've had a look at the f18 branch: $ cat freediams/sources e014e81b349ef5d41bdb956653fb18ab freemedformsfullsources-0.7.5.tgz $ cat freemedforms/sources e014e81b349ef5d41bdb956653fb18ab freemedformsfullsources-0.7.5.tgz ??? _Why_ has it been done like that? Two reasons: - In the past, the build system wasn't as good as it is now. - Since they are two *completely* different applications, we thought it'd be better + easier to review them separately when we initially packaged them up. and use the same internal libraries. Currently, I first build freemedforms-emr and the common libraries (spec[4]) and then build freediams (spec[5]), pointing to these libraries. Is it strictly required to build stuff from freemedforms src.rpm _before_ freediams could be built from the same tarball? Would it have been possible to build both from within a single src.rpm? Yes. It's a must since freediams requires the *same* internal libraries that are built during the freemedforms build. Ideally, if they were built differently, both would generate the libraries during their respective build processes. Instead of doing this, and duplicating the libraries, I build the libraries only once with freemedforms and then point the freediams build to them. If I build them from the same src.rpm, I'll do: cmake...# build freemedforms with libraries cmake...# point to already built libraries and build freediams (This is what upstream's spec also does. It doesn't use one cmake command to build everything) Recently, with the 0.9.0-beta1 release, upstream sent me a new spec and suggested I use one spec to build both freedmedforms and freediams, and provide freediams as a subpackage. I've built freemedforms already, and I'm in the process of updating freediams now. I think it's a good idea, since they'll always move hand in hand. The build process will be simpler, and so will maintaining the package and updates. What do you folks think? Should I go ahead and retire(obsolete) freediams and provide it as a subpackage in freemedforms? I don't see any issues with this, but wanted to consult you folks to be sure before I go ahead and make the changes. Of course! If that hasn't been possible before and now _is_ possible with 0.9.0-beta1, it's the better choice than duplicating the source tarball. Great. I wanted to be sure of this before I went around obsoleting packages etc. I'll combine them whenever I find the cycles. -- 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: Protection from merge commits
On Wed, Sep 11, 2013 at 04:13:43PM -0600, Pete Zaitcev wrote: Dear All: I found that I pushed a merge node into Fedora git (fortunately it was only on f19 branch, not in Rawhide): commit 51eec48c20ba57054f17ba29f23e6a0aa36df9a4 Merge: ac36771 f9213a5 Author: Pete Zaitcev zait...@kotori.zaitcev.us Date: Wed Aug 7 12:14:15 2013 -0600 Merge branch 'f19' of ssh://pkgs.fedoraproject.org/openstack-swift into f19 Thought I was careful about them, but apparently not enough. So, does anyone have a script that can be attached to git hooks, reliably detects an attempt to push merge nodes, then bails the push? The attached script is what we use in libvirt for preventing merge commits being pushed to the main repo. Copy that to your hooks directory naming the file 'update'. Then edit your .git/config file to set [hooks denymerge] master = true It can also be used to prevent creation of new branches or to block commits which have trailing whitespace at the end of line eg by setting [hooks] allowbadwhitespace = false denycreatebranch = true See the script for other possible config options Regards, Daniel -- |: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| #!/bin/sh # # An example hook script to block unannotated tags from entering. # Called by git receive-pack with arguments: refname sha1-old sha1-new # # To enable this hook, rename this file to update. # # Config # -- # hooks.allowunannotated # This boolean sets whether unannotated tags will be allowed into the # repository. By default they won't be. # hooks.allowdeletetag # This boolean sets whether deleting tags will be allowed in the # repository. By default they won't be. # hooks.allowmodifytag # This boolean sets whether a tag may be modified after creation. By default # it won't be. # hooks.allowdeletebranch # This boolean sets whether deleting branches will be allowed in the # repository. By default they won't be. # hooks.denycreatebranch # This boolean sets whether remotely creating branches will be denied # in the repository. By default this is allowed. # # hooks.allowbadwhitespace # This boolean sets whether you may push a commit that adds bad whitespace. # By default, you may not. # # hooks.denypush.branch.BRANCH_NAME # If defined to a string that looks like an email address, this option # disables push access to the specified branch. When a push fails as # a result of this option, the resulting diagnostic includes the specified # email address. For example, run this on the server to deny all push # access to master: # # For example, enable it with this: # git config hooks.denypush.branch.master master-branch-ow...@example.com # # hooks.denymerge.BRANCH_NAME # When this boolean is true, you may not push a merge commit to BRANCH_NAME. # By default, you may. # # - # Allow people to change server-side git config in very specific ways. # To enable this, on the server, you must do something like the following, # # git config hooks.server.config-changing.valid-commands \ # 'git config hooks.allowbadwhitespace true # git config hooks.allowbadwhitespace false # git config hooks.denypush.branch.master master-branch-ow...@example.com # git config --unset hooks.denypush.branch.master' # # where the git config variable, hooks.server.config-changing.valid-commands, # contains the list of commands that are allowed, one per line. # # CAUTION: nothing about this hook code enforces the restriction that # only git config ... commands be run automatically. # That restriction comes solely from the list above. # # Then, when someone with a cloned repository wants to make the hook # run one of those commands *on* *the* *server*, that user must push # a tag whose name starts with git-control- and whose one-line message # matches exactly one of the listed commands. # # For example, to temporarily allow someone to push a bad-whitespace # commit, with the settings implied above, you might do this: # # first_commit=$(git log --reverse --pretty=%H |head -1) # git tag -m 'git config hooks.allowbadwhitespace true' \ # git-control-$(date +%F-%H-%M-%S.%N) $first_commit # # Note that we're not tagging HEAD, but rather the very first commit # in the repository, in an attempt not to clutter up gitk/gitweb # displays with these rarely-interesting tag names. # # Then, to reenable that hook, do this (nearly the same, except s/true/false/): # # first_commit=$(git log --reverse --pretty=%H |head -1) # git tag -m 'git config hooks.allowbadwhitespace false' \ # git-control-$(date +%F-%H-%M-%S.%N) $first_commit #
Re: fedmsg for voting?
On 09/11/2013 10:05 PM, Bill Nottingham wrote: Ralf Corsepius (rc040...@freenet.de) said: - a record of who voted for what has been kept since this feature was implemented: fedorahosted.org/elections/ticket/30 http://fedorahosted.org/elections/ticket/30 in 2009. All election software that recorded this information has kept the information private. You'd go to jail in Germany, if this SW was used for official elections. The laws prevent a voter-verifiable trail that their vote was recorded and cast for who they intended to cast it for, in case of recounts or similar occurences? Correct. a) Votes are organized in a way, there is no trail from person has voted to person's vote. Usually, this is achieved by voting cards carrying no ID. You present a voting register card in the voting office and receive an entirely anonymous voting card. b) All voting registers and voting cards will be destroyed after an election has been announce finalized/certified by officials. The reason for things being this way is freedom and anonymity of voting, because history has told such ID-vote pairs can be abused and because voters, who know such info exists and might be monitored, vote differently. Think about having voted for the SPD or KPD (Socialist or Communist Party) under Hitler Germany nor not having voted in the GDR (where participating in elections was mandatory and non-voters were facing oppression). I can see requiring it be purged after results are certified, This is what is being applied, but I don't know about the details of the proceedings. but there are systems that have required this level of verification be available to voters. Not in Federal-, State- or County-parliament elections and similar in Germany. Ralf -- 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: fedmsg for voting?
On 09/12/2013 03:02 AM, Matthew Miller wrote: On Thu, Sep 12, 2013 at 02:10:05AM +0200, Björn Persson wrote: Since this discussion is now about national elections, which must be taken much more seriously than polls on release names: Can you propose a mechanism that allows the voter to verify his vote at a later time, but does not allow the voter to prove to someone else that he voted for the candidate he was paid to vote for, and does not allow a dominant father to verify that the family members voted like he ordered them to vote? This is not a trivial problem to solve. Like this: http://www.iacr.org/cryptodb/data/paper.php?pubkey=1914 But, yeah. Let's drift back to topic here. What if we made this like the I voted stickers -- you can get one by checking a box in the voting app? (Even if, by the way, you cast no actual votes?) And not wearing such a badge makes you a dissident or terrorist? Ralf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
[Bug 1007314] New: perl-IO-Socket-IP-0.23 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1007314 Bug ID: 1007314 Summary: perl-IO-Socket-IP-0.23 is available Product: Fedora Version: rawhide Component: perl-IO-Socket-IP Keywords: FutureFeature, Triaged Assignee: psab...@redhat.com Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: mmasl...@redhat.com, perl-de...@lists.fedoraproject.org, psab...@redhat.com Latest upstream release: 0.23 Current version/release in Fedora Rawhide: 0.22-2.fc20 URL: http://search.cpan.org/dist/IO-Socket-IP/ 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=6BQTbiQ3Dxa=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: Protection from merge commits
Pete Zaitcev zait...@redhat.com wrote: Thought I was careful about them, but apparently not enough. So, does anyone have a script that can be attached to git hooks, reliably detects an attempt to push merge nodes, then bails the push? I presume that that would prevent valid merging between branches in the repo? For example, I have a reasonably simple package that I apply patches to in the master branch and then merge everything back into the last few Fedora version branches. Usually merge just fast-forwards the branch, but occasionally there has been a mass-rebuild that threw an extra commit in that then needs dealing with. I presume I would then need to pick all the commits instead? David -- 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: F20 KDE session login options
On 12 September 2013 08:34, Martin Briza mbr...@redhat.com wrote: On Thu, 12 Sep 2013 02:17:48 +0200, Michael Catanzaro mike.catanz...@gmail.com wrote: On Thu, 2013-09-12 at 00:13 +0100, Ian Malone wrote: 1. This is the case for the KDE live CD install too. 2. Where the custom session might be coming from (wondering if something specific to this spin or the KDE spins in gene It comes from SDDM directly. Looks like https://bugzilla.redhat.com/show_bug.cgi?id=1004902 Exactly, thank you. Sorry, should have checked BZ first, that looks like it. -- imalone http://ibmalone.blogspot.co.uk -- 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: Scala package owner unresponsive
Great news! Thanks for doing this.
Do you have the log output of the failing tests?
Also, the Source0 URL doesn't work (404) with the new layout of the
scala-lang website, it should now be
http://www.scala-lang.org/files/archive/scala-sources-%{fullversion}.tgz;
On Thu, Sep 12, 2013 at 4:32 AM, Will Benton wi...@redhat.com wrote:
I have made a spec file for Scala 2.10.1 that successfully builds under mock
on F19; it is available here:
https://github.com/willb/scala-packaging
I had to make a new patch to account for interface changes in JLine 2.7,
disable optimization (due to a known bug in the Scala optimizer), and disable
several tests that failed spuriously (as far as I can tell). But I think the
package should be at least as good as the one we had before.
Jochen Schmitt, are you willing to update the build in F19 and rawhide with
these fixes?
- Original Message -
From: Will Benton wi...@redhat.com
To: Development discussions related to Fedora
devel@lists.fedoraproject.org
Sent: Thursday, September 5, 2013 5:26:23 PM
Subject: Re: Scala package owner unresponsive
I see that scala is on the to-be-retired list unless it starts building from
source. I am interested in using Scala in Fedora, and will take on
maintainership (for a while, at least) if no one else is willing to fix it.
- Original Message -
From: Jochen Schmitt joc...@herr-schmitt.de
To: Development discussions related to Fedora
devel@lists.fedoraproject.org
Sent: Thursday, August 22, 2013 6:03:46 AM
Subject: Re: Scala package owner unresponsive
On Sun, Aug 18, 2013 at 09:41:52PM -0600, Jerry James wrote:
On Sun, Aug 18, 2013 at 9:35 PM, Will Benton wi...@redhat.com wrote:
(1) As far as I can tell, the package for Scala 2.9.2 on F19 (2.9.2-2)
has broken dependencies; I can't install it via yum on my new F19
install. Is this the case for anyone else? If so, wouldn't it be best
to have a working Scala 2.9 package in F19 and introduce 2.10 in a
later
release?
Version 2.9.2-4 was built for F-18, but was never built for F-19 or
F-20. The changelog entries for -3 and -4 say:
Yes, the reason fot this is very simple. On F18 we had a jdk-1.6.0
environment in
addition to the jdk-1.7.0. Scala was built explicitly agains jdk-1.6.0
because jdk-1.7.0
is not supported on this release.
Fedora 19 and late doesn't provides a jdk-1.6.0 environment which is the
reason
for the broken dependency. So it's impossible to build scala-2.9.x for F19
or
later releases for Fedora.
Best Regards:
Jochen Schmitt
--
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
--
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
I am thinking of adding compression to libselinux
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Basically looking at compressing the policy file to shrink SELinux footprint in the minimal install/cloud image. Currently the policy modules (pp files) are shipped with bzip compression but the actually policy file. But the /etc/selinux/targeted/policy/policy.29 is not compressed. systemd and load_policy use libselinux to read in the policy file and load it into the kernel, so since systemd currently uses libxz, I figured this would be the best solution to add libxz support to libselinux. ls -l /etc/selinux/targeted/policy/policy.29* - -rw-r--r--. 1 root root 2703245 Sep 11 13:56 /etc/selinux/targeted/policy/policy.29 - -rw-r--r--. 1 root root 395072 Sep 11 13:56 /etc/selinux/targeted/policy/policy.29.xz Worth the effort? Should I use a different algorithm? Advise on using libxz? Keep memory small? -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.14 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlIxqzoACgkQrlYvE4MpobMnkACgk+NeEeHuFSECZwoHF9B3UmTb fCYAn2BfSemECcSPXIxCd7OCSkyIOXgO =ZD3h -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] F20 Alpha Testing Status: Last Minute Assistance Requested
We ended up needing a RC2 spin for alpha to fix a bug we thought was fixed for almost all machines [1] and we're now in the situation where most of the alpha validation test cases need to be run in less than 12 hours if we don't want F20 alpha to slip. Fortunately, this is alpha and there aren't nearly so many test cases to run through but more people to run them would be really appreciated. If you have some time, grab a Fedora 20 alpha RC2 image [2] and run through a test case marked alpha on either the installation matrix [3] or the desktop test matrix [4]. If you're more of a cloud person, take the RC1 AMIs [5] for a spin - the changes between RC1 and RC2 are inconsequential for the cloud image and results for the openstack or AMI images can be entered in either the RC1 install matrix [6]. Thanks in advance, Tim [1]https://bugzilla.redhat.com/show_bug.cgi?id=997690 [2]http://dl.fedoraproject.org/pub/alt/stage/20-Alpha-RC2/ [3]https://fedoraproject.org/wiki/Test_Results:Fedora_20_Alpha_RC2_Install [4]https://fedoraproject.org/wiki/Test_Results:Fedora_20_Alpha_RC2_Desktop [5]https://lists.fedoraproject.org/pipermail/test/2013-September/117657.html [6]https://fedoraproject.org/wiki/Test_Results:Fedora_20_Alpha_RC2_Install signature.asc Description: PGP signature ___ 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
Re: I am thinking of adding compression to libselinux
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Basically looking at compressing the policy file to shrink SELinux footprint in the minimal install/cloud image. Currently the policy modules (pp files) are shipped with bzip compression but the actually policy file. But the /etc/selinux/targeted/policy/policy.29 is not compressed. systemd and load_policy use libselinux to read in the policy file and load it into the kernel, so since systemd currently uses libxz, I figured this would be the best solution to add libxz support to libselinux. ls -l /etc/selinux/targeted/policy/policy.29* - -rw-r--r--. 1 root root 2703245 Sep 11 13:56 /etc/selinux/targeted/policy/policy.29 - -rw-r--r--. 1 root root 395072 Sep 11 13:56 /etc/selinux/targeted/policy/policy.29.xz Worth the effort? Should I use a different algorithm? Advise on using libxz? Keep memory small? -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.14 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlIxqzoACgkQrlYvE4MpobMnkACgk+NeEeHuFSECZwoHF9B3UmTb fCYAn2BfSemECcSPXIxCd7OCSkyIOXgO =ZD3h -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 If the loss of time when loading selinux-policy (not a one policy module, but all of them) will not be large, it is worth 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: I am thinking of adding compression to libselinux
On Thu, 12.09.13 07:53, Daniel J Walsh (dwa...@redhat.com) wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Basically looking at compressing the policy file to shrink SELinux footprint in the minimal install/cloud image. Currently the policy modules (pp files) are shipped with bzip compression but the actually policy file. But the /etc/selinux/targeted/policy/policy.29 is not compressed. systemd and load_policy use libselinux to read in the policy file and load it into the kernel, so since systemd currently uses libxz, I figured this would be the best solution to add libxz support to libselinux. ls -l /etc/selinux/targeted/policy/policy.29* - -rw-r--r--. 1 root root 2703245 Sep 11 13:56 /etc/selinux/targeted/policy/policy.29 - -rw-r--r--. 1 root root 395072 Sep 11 13:56 /etc/selinux/targeted/policy/policy.29.xz Worth the effort? Well, you might buy smaller footprint with slower boot time, but I figure without trying it there's no way to know that for sure. (That said, our minimal image is a couple of 100mb still, iirc, so 2mb is not tht much.) Should I use a different algorithm? Advise on using libxz? Keep memory small? I think nowadays it's either gzip or xz, and everything else is not interesting, as the others either are slower or compress worses, and most importantly: libgz/liblzma are deps of the core OS anyway and included in the minimal image anyway and are also already mapped into memory, so come basically free. Lennart -- Lennart Poettering - 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: numatop: %{optflags} fail the 32bit build
Hi,
On Wed, Sep 11, 2013 at 8:46 AM, Florian Weimer fwei...@redhat.com wrote:
On 09/11/2013 12:31 AM, Dridi Boukelmoune wrote:
I have my first packaging issue on the numatop package[1].
During the review it appeared that I forgot the %{optflags}, and that
adding them breaks the i686 build. The upstream dev is very patient
and willing to help me, but I feel I have wasted enough of his time.
The guilty gcc flag seems to be:
-specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 [2]
It would be helpful to provide more context and pointers to the analysis so
far.
The failing build log is here:
http://kojipkgs.fedoraproject.org//work/tasks/1414/5911414/build.log
This is the offending function:
void
cpuid(unsigned int *eax, unsigned int *ebx, unsigned int *ecx,
unsigned int *edx)
{
__asm volatile
(cpuid\n\t
: =a (*eax),
=b (*ebx),
=c (*ecx),
=d (*edx)
: a (*eax));
}
The cryptic GCC error message (inconsistent operand constraints in an ‘asm’)
refers to the fact that in PIC mode (which is activated by the hardening
flags), %ebx is a reserved register.
Thanks for the explanation, I could never have figured this out.
This version should work in 32 bit mode, and only in 32 bit mode:
void
cpuid(unsigned int *eax, unsigned int *ebx, unsigned int *ecx,
unsigned int *edx)
{
__asm volatile
(push %%ebx\n\t
cpuid\n\t
mov %%ebx, (%1)\n\t
pop %%ebx
: =a (*eax),
=S (ebx),
=c (*ecx),
=d (*edx)
: 0 (*eax));
}
I kind of understand what you're doing here, but it's not all clear.
I get the push/pop instructions save and restore the reserved ebx
register, which is needed because apparently the cpuid instruction
would otherwise overwrite it.
I don't understand the mov instruction, but I suppose you're storing
ebx's value from cpuid somewhere else before restoring it with the
pop instruction.
I don't understand the last 5 lines of __asm in both functions, I've
never seen this syntax before.
I have not actually tested this. There are other solutions floating around,
but they are clearly incorrect and produce wrong code.
It builds, but it segfaults. Probably because the value is written
directly in the ebx variable, which is a pointer. I've added a temp
variable to fix the segfault, but I still need to check whether it
gives the expected value:
void
cpuid(unsigned int *eax, unsigned int *ebx, unsigned int *ecx,
unsigned int *edx)
{
#ifdef __x86_64
// original version
#else
unsigned int tmp;
__asm volatile
(push %%ebx\n\t
cpuid\n\t
mov %%ebx, (%1)\n\t
pop %%ebx
: =a (*eax),
=S (tmp),
=c (*ecx),
=d (*edx)
: 0 (*eax));
*ebx = tmp;
#endif
}
I don't actually have the code on this computer but I remember doing
something like that, so this is only pseudo code :)
In 64 bit mode, you should use the original version.
--
Florian Weimer / Red Hat Product Security Team
Thank you both for your help, I'll find some time this weekend to test
it further before sending it back to the upstream project.
Dridi
--
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: Heads up! I'm going to upgrade Wireshark up to 1.10.x in Fedora 18
On Thu, 12 Sep 2013 10:42:20 +0200, Peter Lemenkov wrote: I'm afraid that's just adds additional work for maintainers w/o any visible benefits. The benefits are the stable Fedora release does not break 3rd party applications during its deployment/lifecycle. Let's move further instead of backporting - that's just a leafnode app so nobody got hurt by a potential dependency issue. wireshark.rpm contains many commandline utilities which may be used by 3rd party sysadmin scripts (and maybe even 3rd party C applications). further in your explanation means nullifying the long Fedora alpha/beta release engineering and also nullifying the upstream efforts to release 1.8.x versions even after 1.10.0 had been already released. joke So let's drop the Fedora releases effort and we can all just run Rawhide. /joke Regards, Jan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: I am thinking of adding compression to libselinux
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 09/12/2013 08:11 AM, Lennart Poettering wrote: On Thu, 12.09.13 07:53, Daniel J Walsh (dwa...@redhat.com) wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Basically looking at compressing the policy file to shrink SELinux footprint in the minimal install/cloud image. Currently the policy modules (pp files) are shipped with bzip compression but the actually policy file. But the /etc/selinux/targeted/policy/policy.29 is not compressed. systemd and load_policy use libselinux to read in the policy file and load it into the kernel, so since systemd currently uses libxz, I figured this would be the best solution to add libxz support to libselinux. ls -l /etc/selinux/targeted/policy/policy.29* - -rw-r--r--. 1 root root 2703245 Sep 11 13:56 /etc/selinux/targeted/policy/policy.29 - -rw-r--r--. 1 root root 395072 Sep 11 13:56 /etc/selinux/targeted/policy/policy.29.xz Worth the effort? Well, you might buy smaller footprint with slower boot time, but I figure without trying it there's no way to know that for sure. (That said, our minimal image is a couple of 100mb still, iirc, so 2mb is not tht much.) Should I use a different algorithm? Advise on using libxz? Keep memory small? I think nowadays it's either gzip or xz, and everything else is not interesting, as the others either are slower or compress worses, and most importantly: libgz/liblzma are deps of the core OS anyway and included in the minimal image anyway and are also already mapped into memory, so come basically free. Lennart Well I will need to support both compressed and uncompressed versions, so I guess I could set up the tooling to create either based on config. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.14 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlIxsKAACgkQrlYvE4MpobPSxgCgu7jKV1tFBzvdWOg3vRLU5HXr 2pQAn3nWXA0pUroTJXx+Iy7e+kYvu6Pj =qUnS -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: Heads up! I'm going to upgrade Wireshark up to 1.10.x in Fedora 18
On Thu, Sep 12, 2013 at 8:12 PM, Jan Kratochvil jan.kratoch...@redhat.com wrote: joke So let's drop the Fedora releases effort and we can all just run Rawhide. /joke It's not a joke now in some cases. -- 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: I am thinking of adding compression to libselinux
On Thu, 12.09.13 08:16, Daniel J Walsh (dwa...@redhat.com) wrote: Well, you might buy smaller footprint with slower boot time, but I figure without trying it there's no way to know that for sure. (That said, our minimal image is a couple of 100mb still, iirc, so 2mb is not tht much.) Should I use a different algorithm? Advise on using libxz? Keep memory small? I think nowadays it's either gzip or xz, and everything else is not interesting, as the others either are slower or compress worses, and most importantly: libgz/liblzma are deps of the core OS anyway and included in the minimal image anyway and are also already mapped into memory, so come basically free. Lennart Well I will need to support both compressed and uncompressed versions, so I guess I could set up the tooling to create either based on config. Well, it could be that fewer disk accesses and stuff might actually speed things up when you compress things, in which case doing the compression is faster and smaller, in which case i see no point in supporting anything but the compressed version... Lennart -- Lennart Poettering - 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: numatop: %{optflags} fail the 32bit build
On 09/12/2013 02:11 PM, Dridi Boukelmoune wrote: I don't understand the last 5 lines of __asm in both functions, I've never seen this syntax before. It's gcc's extended asm syntax (Aka. inline asm in C): c.f. http://gcc.gnu.org/onlinedocs/gcc/Extended-Asm.html ff. Ralf -- 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: numatop: %{optflags} fail the 32bit build
On 09/12/2013 02:11 PM, Dridi Boukelmoune wrote:
This version should work in 32 bit mode, and only in 32 bit mode:
void
cpuid(unsigned int *eax, unsigned int *ebx, unsigned int *ecx,
unsigned int *edx)
{
__asm volatile
(push %%ebx\n\t
cpuid\n\t
mov %%ebx, (%1)\n\t
pop %%ebx
: =a (*eax),
=S (ebx),
=c (*ecx),
=d (*edx)
: 0 (*eax));
}
I kind of understand what you're doing here, but it's not all clear.
I get the push/pop instructions save and restore the reserved ebx
register, which is needed because apparently the cpuid instruction
would otherwise overwrite it.
I don't understand the mov instruction, but I suppose you're storing
ebx's value from cpuid somewhere else before restoring it with the
pop instruction.
Correct, the intent is to write the %ebx register value to the address
in the %esi register. (%1) is a pointer dereference, as oppose to
plain %1.
I don't understand the last 5 lines of __asm in both functions, I've
never seen this syntax before.
These are register constraints. a, c, d, S refer to the %eax,
%ecx, %edx, %esi registers, respectively. = marks output constraints.
The constraints before the final : are output registers, and after
colon, there are the input registers. There's just one, and 0 means
to reuse the first output register.
Okay, silly me, I should have listed S among the output registers,
instead the inputs:
void
cpuid(unsigned int *eax, unsigned int *ebx, unsigned int *ecx,
unsigned int *edx)
{
__asm volatile
(push %%ebx\n\t
cpuid\n\t
mov %%ebx, (%4)\n\t
pop %%ebx
: =a (*eax),
=c (*ecx),
=d (*edx)
: 0 (*eax),
S (ebx));
}
I also forget that for full correctness, there should now be a memory
clobber as well (in the clobber section after yet another colon):
void
cpuid(unsigned int *eax, unsigned int *ebx, unsigned int *ecx,
unsigned int *edx)
{
__asm volatile
(push %%ebx\n\t
cpuid\n\t
mov %%ebx, (%4)\n\t
pop %%ebx
: =a (*eax),
=c (*ecx),
=d (*edx)
: 0 (*eax),
S (ebx)
: memory);
}
By the way, we could generate much better code if the registers were
passed as an array or struct, so that they are in consecutive memory:
struct regs {
unsigned eax, ebx, ecx, edx;
};
void
cpuid(struct regs *r)
{
__asm volatile
(push %%ebx\n\t
cpuid\n\t
mov %%eax, (%0)\n\t
mov %%ebx, 4(%0)\n\t
mov %%ecx, 8(%0)\n\t
mov %%edx, 12(%0)\n\t
pop %%ebx
:
: S (r)
: eax, ecx, edx, memory);
}
Obviously, this needs adjustments to the callers.
--
Florian Weimer / Red Hat Product Security 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
Re: [389-devel] 389-devel Digest, Vol 99, Issue 6
On 09/11/2013 07:41 PM, Howard Chu wrote: 389-devel-requ...@lists.fedoraproject.org wrote: Send 389-devel mailing list submissions to 389-de...@lists.fedoraproject.org To subscribe or unsubscribe via the World Wide Web, visit https://admin.fedoraproject.org/mailman/listinfo/389-devel or, via email, send a message with subject or body 'help' to 389-devel-requ...@lists.fedoraproject.org You can reach the person managing the list at 389-devel-ow...@lists.fedoraproject.org When replying, please edit your Subject line so it is more specific than Re: Contents of 389-devel digest... Today's Topics: 1. Re: RFC: New Design: Fine Grained ID List Size (Rich Megginson) 2. Re: RFC: New Design: Fine Grained ID List Size (Ludwig Krispenz) -- Message: 1 Date: Tue, 10 Sep 2013 08:29:14 -0600 From: Rich Megginson rmegg...@redhat.com To: Ludwig Krispenz lkris...@redhat.com Cc: 389 Directory server developer discussion. 389-de...@lists.fedoraproject.org Subject: Re: [389-devel] RFC: New Design: Fine Grained ID List Size Message-ID: 522f2cba.1040...@redhat.com Content-Type: text/plain; charset=UTF-8; format=flowed On 09/10/2013 01:47 AM, Ludwig Krispenz wrote: On 09/09/2013 07:19 PM, Rich Megginson wrote: On 09/09/2013 02:27 AM, Ludwig Krispenz wrote: On 09/07/2013 05:02 AM, David Boreham wrote: On 9/6/2013 8:49 PM, Nathan Kinder wrote: This is a good idea, and it is something that we discussed briefly off-list. The only downside is that we need to change the index format to keep a count of ids for each key. Implementing this isn't a big problem, but it does mean that the existing indexes need to be updated to populate the count based off of the contents (as you mention above). I don't think you need to do this (I certainly wasn't advocating doing so). The statistics state is much the same as that proposed in Rich's design. In fact you could probably just use that same information. My idea is more about where and how you use the information. All you need is something associated with each index that says not much point looking here if you're after something specific, move along, look somewhere else instead. This is much the same information as don't use a high scan limit here. In the short term, we are looking for a way to be able to improve performance for specific search filters that are not possible to modify on the client side (for whatever reason) while leaving the index file format exactly as it is. I still feel that there is potentially great value in keeping a count of ids per key so we can optimize things on the server side automatically without the need for complex index configuration on the administrator's part. I think we should consider this for an additional future enhancement. I'm saying the same thing. Keeping a cardinality count per key is way more than I'm proposing, and I'm not sure how useful that would be anyway, unless you want to do OLAP in the DS ;) we have the cardinality of the key in old-idl and this makes some searches where parts of the filter are allids fast. I'm late in the discussion, but I think Rich's proposal is very promising to address all the problems related to allids in new-idl. We could then eventually rework filter ordering based on these configurations. Right now we only have a filter ordering based on index type and try to postpone = or similar filter as they are known to be costly, but this could be more elaborate. An alternative would be to have some kind of index lookup caching. In the example in ticket 47474 the filter is ((|(objectClass=organizationalPerson)(objectClass=inetOrgPerson)(objectClass=organization)(objectClass=organizationalUnit)(objectClass=groupOf Names)(objectClass=groupOfUniqueNames)(objectClass=group))(c3sUserID=EndUser078458)) and probably only the c3sUserID=x part will change, if we cache the result for the ((|(objectClass=... part, even if it is expensive, it would be done only once. Thanks everyone for the comments. I have added Noriko's suggestion: http://port389.org/wiki/Design/Fine_Grained_ID_List_Size David, Ludwig: Does the current design address your concerns, and/or provide the necessary first step for further refinements? yes, the topic of filter reordering or caching could be looked at independently. Just one concern abou the syntax: nsIndexIDListScanLimit: maxsize[:indextype][:flag[,flag...]][:value[,value...]] since everything is optional, how do you decide if in nsIndexIDListScanLimit: 6:eq:AND AND is a value or a flag ? and as it defines limits for specific keys, could the attributname reflect this, eg nsIndexKeyIDListScanLimit or nsIndexKeyScanLimit or ... ? Thanks, yes, it is ambiguous. I think it may have to use keyword=value, so something like this: nsIndexIDListScanLimit: limit=NNN [type=eq[,sub]] [flags=ADD[,OR]] [values=val[,val...]] That should be easy to parse for both humans and
Re: fedmsg for voting?
On Wed, Sep 11, 2013 at 09:23:44PM -0700, Toshio Kuratomi wrote: On Sep 11, 2013 6:02 PM, Matthew Miller mat...@fedoraproject.org wrote: What if we made this like the I voted stickers -- you can get one by checking a box in the voting app? (Even if, by the way, you cast no actual votes?) I had thought that this would trigger off of someone hitting submit on the election page. That should vote 0 for all candidates if no votes are assigned but still meet the trigger condition. Not sure if that meets the criteria for objectors, though. Ralph bean should weigh in here as to whether logged in during an election period would also be suitable (which was something that people seemed to think would be acceptable earlier in the thread). Hm, its not worth doing if we're going to make it complex like this. I think we should just drop it. No fedmsg broadcast for votes, only for election period opening/closing and only for election results publication/retraction by the admin (with obviously no user participation data included). It is just not important enough to: 1) cause anyone any worry. 2) bother engineering a complicated compromise solution. If someone wants to argue that we still try to make it happen, I'll hear that and implement it if a consensus is formed. (FWIW, personally I'm still all for it). pgpwTp59vTV_M.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: numatop: %{optflags} fail the 32bit build
On 09/12/2013 02:53 PM, Florian Weimer wrote:
By the way, we could generate much better code if the registers were
passed as an array or struct, so that they are in consecutive memory:
struct regs {
unsigned eax, ebx, ecx, edx;
};
void
cpuid(struct regs *r)
{
__asm volatile
(push %%ebx\n\t
cpuid\n\t
mov %%eax, (%0)\n\t
mov %%ebx, 4(%0)\n\t
mov %%ecx, 8(%0)\n\t
mov %%edx, 12(%0)\n\t
pop %%ebx
:
: S (r)
: eax, ecx, edx, memory);
}
Okay, I forgot to load the %eax register. This version has actually
been tested (on x86_64):
void
cpuid(struct regs *r)
{
__asm volatile
(mov (%0), %%eax\n\t
push %%rbx\n\t
cpuid\n\t
mov %%eax, (%0)\n\t
mov %%ebx, 4(%0)\n\t
mov %%ecx, 8(%0)\n\t
mov %%edx, 12(%0)\n\t
pop %%rbx
:
: D (r)
: eax, ecx, edx, memory);
}
D picks the %edi register, which saves another move because it
contains the first function parameter on x86_64.
For the i386 version, replace %rbx with %ebx.
--
Florian Weimer / Red Hat Product Security 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
Re: I am thinking of adding compression to libselinux
On Thu, Sep 12, 2013 at 02:11:04PM +0200, Lennart Poettering wrote: (That said, our minimal image is a couple of 100mb still, iirc, so 2mb is not tht much.) It's basically down to the three big unsolved problems (kernel modules, translations, docs) and then several dozen little things like this. If getting really small is a priority we need to solve the big problems, but chipping away at the little things helps too. I think nowadays it's either gzip or xz, and everything else is not interesting, as the others either are slower or compress worses, and most importantly: libgz/liblzma are deps of the core OS anyway and included in the minimal image anyway and are also already mapped into memory, so come basically free. +1 -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: I am thinking of adding compression to libselinux
On Thu, Sep 12, 2013 at 3:16 PM, Matthew Miller mat...@fedoraproject.org wrote: On Thu, Sep 12, 2013 at 02:11:04PM +0200, Lennart Poettering wrote: (That said, our minimal image is a couple of 100mb still, iirc, so 2mb is not tht much.) It's basically down to the three big unsolved problems (kernel modules, translations, docs) and then several dozen little things like this. If getting really small is a priority we need to solve the big problems, but chipping away at the little things helps too. How about compression at the file system level? -- 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: I am thinking of adding compression to libselinux
On Thu, Sep 12, 2013 at 9:16 AM, Matthew Miller mat...@fedoraproject.org wrote: On Thu, Sep 12, 2013 at 02:11:04PM +0200, Lennart Poettering wrote: (That said, our minimal image is a couple of 100mb still, iirc, so 2mb is not tht much.) It's basically down to the three big unsolved problems (kernel modules, translations, docs) and then several dozen little things like this. If getting really small is a priority we need to solve the big problems, but chipping away at the little things helps too. I'm still thinking about the kernel modules thing. I don't think it's going to be an F20 change, but we might be able to do something for F21 and beyond. josh -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: fedmsg for voting?
On Thu, Sep 12, 2013 at 11:14:34AM +0200, Ralf Corsepius wrote: What if we made this like the I voted stickers -- you can get one by checking a box in the voting app? (Even if, by the way, you cast no actual votes?) And not wearing such a badge makes you a dissident or terrorist? I think we're Godwinning the coversation here. -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Firewall blocking desktop features
On Thu, 2013-09-12 at 10:01 +0300, Oron Peled wrote: * From pid you can find the real executable (/proc/pid/cmd). And this is the step that's worthless: https://bugzilla.gnome.org/show_bug.cgi?id=533493 -- 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: Heads up! I'm going to upgrade Wireshark up to 1.10.x in Fedora 18
Hi, On 09/12/2013 02:12 PM, Jan Kratochvil wrote: On Thu, 12 Sep 2013 10:42:20 +0200, Peter Lemenkov wrote: I'm afraid that's just adds additional work for maintainers w/o any visible benefits. The benefits are the stable Fedora release does not break 3rd party applications during its deployment/lifecycle. Let's move further instead of backporting - that's just a leafnode app so nobody got hurt by a potential dependency issue. wireshark.rpm contains many commandline utilities which may be used by 3rd party sysadmin scripts (and maybe even 3rd party C applications). Correct. further in your explanation means nullifying the long Fedora alpha/beta release engineering and also nullifying the upstream efforts to release 1.8.x versions even after 1.10.0 had been already released. Agree. joke So let's drop the Fedora releases effort and we can all just run Rawhide. /joke Actually, this will make living releases of Fedora kind of Rawhide. As stated in former mail, it would be good to do 1.8.10 upgrade in Fedora 18. Regards, Jan -- Peter Hatina ENG Server Experience, System Management Red Hat Czech, Brno -- 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-perl5i/f19] Initial import (perl-perl5i-2.12.0-3)
Summary of changes: 314aa24... Initial import (perl-perl5i-2.12.0-3) (*) (*) This commit already existed in another branch; no separate mail sent -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Broken dependencies: perl-ParseUtil-Domain
perl-ParseUtil-Domain has broken dependencies in the rawhide tree: On x86_64: perl-ParseUtil-Domain-2.22-3.fc19.noarch requires perl(:MODULE_COMPAT_5.16.2) On i386: perl-ParseUtil-Domain-2.22-3.fc19.noarch requires perl(:MODULE_COMPAT_5.16.2) On armhfp: perl-ParseUtil-Domain-2.22-3.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: perl-MIME-Lite-HTML
perl-MIME-Lite-HTML has broken dependencies in the rawhide 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-PDL
perl-PDL has broken dependencies in the rawhide 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-Locale-Codes
perl-Locale-Codes has broken dependencies in the rawhide tree: On x86_64: perl-Locale-Codes-3.27-1.fc21.noarch requires perl(Locale::Codes::Script_Retired) perl-Locale-Codes-3.27-1.fc21.noarch requires perl(Locale::Codes::Script_Codes) perl-Locale-Codes-3.27-1.fc21.noarch requires perl(Locale::Codes::Language_Retired) perl-Locale-Codes-3.27-1.fc21.noarch requires perl(Locale::Codes::Language_Codes) perl-Locale-Codes-3.27-1.fc21.noarch requires perl(Locale::Codes::LangVar_Retired) perl-Locale-Codes-3.27-1.fc21.noarch requires perl(Locale::Codes::LangVar_Codes) perl-Locale-Codes-3.27-1.fc21.noarch requires perl(Locale::Codes::LangFam_Codes) perl-Locale-Codes-3.27-1.fc21.noarch requires perl(Locale::Codes::LangExt_Retired) perl-Locale-Codes-3.27-1.fc21.noarch requires perl(Locale::Codes::LangExt_Codes) perl-Locale-Codes-3.27-1.fc21.noarch requires perl(Locale::Codes::Currency_Retired) perl-Locale-Codes-3.27-1.fc21.noarch requires perl(Locale::Codes::Currency_Codes) perl-Locale-Codes-3.27-1.fc21.noarch requires perl(Locale::Codes::Country_Retired) perl-Locale-Codes-3.27-1.fc21.noarch requires perl(Locale::Codes::Country_Codes) On i386: perl-Locale-Codes-3.27-1.fc21.noarch requires perl(Locale::Codes::Script_Retired) perl-Locale-Codes-3.27-1.fc21.noarch requires perl(Locale::Codes::Script_Codes) perl-Locale-Codes-3.27-1.fc21.noarch requires perl(Locale::Codes::Language_Retired) perl-Locale-Codes-3.27-1.fc21.noarch requires perl(Locale::Codes::Language_Codes) perl-Locale-Codes-3.27-1.fc21.noarch requires perl(Locale::Codes::LangVar_Retired) perl-Locale-Codes-3.27-1.fc21.noarch requires perl(Locale::Codes::LangVar_Codes) perl-Locale-Codes-3.27-1.fc21.noarch requires perl(Locale::Codes::LangFam_Codes) perl-Locale-Codes-3.27-1.fc21.noarch requires perl(Locale::Codes::LangExt_Retired) perl-Locale-Codes-3.27-1.fc21.noarch requires perl(Locale::Codes::LangExt_Codes) perl-Locale-Codes-3.27-1.fc21.noarch requires perl(Locale::Codes::Currency_Retired) perl-Locale-Codes-3.27-1.fc21.noarch requires perl(Locale::Codes::Currency_Codes) perl-Locale-Codes-3.27-1.fc21.noarch requires perl(Locale::Codes::Country_Retired) perl-Locale-Codes-3.27-1.fc21.noarch requires perl(Locale::Codes::Country_Codes) On armhfp: perl-Locale-Codes-3.27-1.fc21.noarch requires perl(Locale::Codes::Script_Retired) perl-Locale-Codes-3.27-1.fc21.noarch requires perl(Locale::Codes::Script_Codes) perl-Locale-Codes-3.27-1.fc21.noarch requires perl(Locale::Codes::Language_Retired) perl-Locale-Codes-3.27-1.fc21.noarch requires perl(Locale::Codes::Language_Codes) perl-Locale-Codes-3.27-1.fc21.noarch requires perl(Locale::Codes::LangVar_Retired) perl-Locale-Codes-3.27-1.fc21.noarch requires perl(Locale::Codes::LangVar_Codes) perl-Locale-Codes-3.27-1.fc21.noarch requires perl(Locale::Codes::LangFam_Codes) perl-Locale-Codes-3.27-1.fc21.noarch requires perl(Locale::Codes::LangExt_Retired) perl-Locale-Codes-3.27-1.fc21.noarch requires perl(Locale::Codes::LangExt_Codes) perl-Locale-Codes-3.27-1.fc21.noarch requires perl(Locale::Codes::Currency_Retired) perl-Locale-Codes-3.27-1.fc21.noarch requires perl(Locale::Codes::Currency_Codes) perl-Locale-Codes-3.27-1.fc21.noarch requires perl(Locale::Codes::Country_Retired) perl-Locale-Codes-3.27-1.fc21.noarch requires perl(Locale::Codes::Country_Codes) 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-MooseX-TrackDirty-Attributes
perl-MooseX-TrackDirty-Attributes has broken dependencies in the rawhide tree: On x86_64: perl-MooseX-TrackDirty-Attributes-2.002-2.fc19.noarch requires perl(:MODULE_COMPAT_5.16.2) On i386: perl-MooseX-TrackDirty-Attributes-2.002-2.fc19.noarch requires perl(:MODULE_COMPAT_5.16.2) On armhfp: perl-MooseX-TrackDirty-Attributes-2.002-2.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 rawhide 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
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
Broken dependencies: perl-Bio-ASN1-EntrezGene
perl-Bio-ASN1-EntrezGene has broken dependencies in the rawhide tree: On x86_64: perl-Bio-ASN1-EntrezGene-1.091-19.fc20.noarch requires perl(Bio::Index::AbstractSeq) On i386: perl-Bio-ASN1-EntrezGene-1.091-19.fc20.noarch requires perl(Bio::Index::AbstractSeq) On armhfp: perl-Bio-ASN1-EntrezGene-1.091-19.fc20.noarch requires perl(Bio::Index::AbstractSeq) 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-Unix-Statgrab
perl-Unix-Statgrab has broken dependencies in the rawhide tree: On x86_64: perl-Unix-Statgrab-0.04-20.fc20.x86_64 requires libstatgrab.so.6()(64bit) On i386: perl-Unix-Statgrab-0.04-20.fc20.i686 requires libstatgrab.so.6 On armhfp: perl-Unix-Statgrab-0.04-20.fc20.armv7hl requires libstatgrab.so.6 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 rawhide 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
Re: I am thinking of adding compression to libselinux
On Thu, Sep 12, 2013 at 03:18:58PM +0200, drago01 wrote: It's basically down to the three big unsolved problems (kernel modules, translations, docs) and then several dozen little things like this. If getting really small is a priority we need to solve the big problems, but chipping away at the little things helps too. How about compression at the file system level? Helps in some situations and not in others. (We also already compress the qcow2 images we offer, so although xz is a little better this doesn't do much for the network transfer sizes.) -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Scala package owner unresponsive
- Original Message -
From: Antoine Gourlay anto...@gourlay.fr
To: Development discussions related to Fedora
devel@lists.fedoraproject.org
Sent: Thursday, September 12, 2013 6:22:05 AM
Subject: Re: Scala package owner unresponsive
Do you have the log output of the failing tests?
I can probably dig it up, but the breakdown was something like this:
* most of the failures were because they expected different character encodings
than the default in JDK7 (crashing with MalformedInputExceptions)
* a couple of tests (the pax exam for OSGi testing in particular) failed under
rpmbuild but not in a by-hand run in my ~rpmbuild/BUILD directory
* one test failed under mock but not under rpmbuild
Also, the Source0 URL doesn't work (404) with the new layout of the
scala-lang website, it should now be
http://www.scala-lang.org/files/archive/scala-sources-%{fullversion}.tgz;
Thanks for pointing this out. I had caught this in an earlier attempt to fix
this package but missed it this time. The SRPM (2.10.1-4) and spec are now
fixed to reflect this.
best,
wb
--
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: fedmsg for voting?
On Thu, Sep 12, 2013 at 08:59:40AM -0400, Ralph Bean wrote: On Wed, Sep 11, 2013 at 09:23:44PM -0700, Toshio Kuratomi wrote: On Sep 11, 2013 6:02 PM, Matthew Miller mat...@fedoraproject.org wrote: What if we made this like the I voted stickers -- you can get one by checking a box in the voting app? (Even if, by the way, you cast no actual votes?) I had thought that this would trigger off of someone hitting submit on the election page. That should vote 0 for all candidates if no votes are assigned but still meet the trigger condition. Not sure if that meets the criteria for objectors, though. Ralph bean should weigh in here as to whether logged in during an election period would also be suitable (which was something that people seemed to think would be acceptable earlier in the thread). Hm, its not worth doing if we're going to make it complex like this. I think we should just drop it. No fedmsg broadcast for votes, only for election period opening/closing and only for election results publication/retraction by the admin (with obviously no user participation data included). It is just not important enough to: 1) cause anyone any worry. 2) bother engineering a complicated compromise solution. If someone wants to argue that we still try to make it happen, I'll hear that and implement it if a consensus is formed. (FWIW, personally I'm still all for it). I tend to align with Ralph on this. I do think there is interest and even benefit from having a badge system coupled with the elections. If only because we have 2436 (on Thu Sep 12 13:56:25 UTC 2013) people registered on badges while for the last elections we had: - FESCO: 200 ballots - Board: 204 ballots There is the risk of having people voting just to get the badges, but there is also the possibility of motivating people to follow the elections and vote thanks to the badge system. However, the discussion here seems to indicate that a number of person do not like the idea of been marked as Has voted (w/o any other information) and unless more people express their opinion, then so be it :) My 2 cts, Pierre pgpMn1UxK4m4F.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Packages requiring Xorg BackingStore true
On Wed, 2013-09-11 at 23:27 +0200, Sandro Mani wrote: Well, yes, but it ought to work regardless of the xorg.conf setting, because that setting has been effectively hardwired to true for about six years now. I rewrote the backing store implementation to use Composite internally, which is always available, so we just blindly ignore the config setting and give you backing store if you ask for it. There may be bugs, I freely admit, but it's definitely meant to work. If it doesn't it's probably a bug in X and I'll fix it, so hook me up with test packages and I'll take a look. I've uploaded an x86_64 rpm here [1], the srpm is here [2]. To reproduce the problem, first download the foil gometry [3], then run xfoil from a terminal, and type load Naca63412.dat and at the following Enter airfoil name prompt, type naca63412 Upon pressing enter, the Xplot11 window should open, showing the cross-section of the foil. The Xlib code for the plotting window is in plotlib/Xwin.c in the xfoil source tarball. Oh my, this is embarassing. If only I'd deleted more code you'd never have hit this. Definitely a bug in xserver. I'll send a patch upstream and fix Fedora once that lands. Thanks for the testcase! - ajax -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: fedmsg for voting?
On Thu, Sep 12, 2013 at 04:08:21PM +0200, Pierre-Yves Chibon wrote: On Thu, Sep 12, 2013 at 08:59:40AM -0400, Ralph Bean wrote: On Wed, Sep 11, 2013 at 09:23:44PM -0700, Toshio Kuratomi wrote: On Sep 11, 2013 6:02 PM, Matthew Miller mat...@fedoraproject.org wrote: What if we made this like the I voted stickers -- you can get one by checking a box in the voting app? (Even if, by the way, you cast no actual votes?) I had thought that this would trigger off of someone hitting submit on the election page. That should vote 0 for all candidates if no votes are assigned but still meet the trigger condition. Not sure if that meets the criteria for objectors, though. Ralph bean should weigh in here as to whether logged in during an election period would also be suitable (which was something that people seemed to think would be acceptable earlier in the thread). Hm, its not worth doing if we're going to make it complex like this. I think we should just drop it. No fedmsg broadcast for votes, only for election period opening/closing and only for election results publication/retraction by the admin (with obviously no user participation data included). It is just not important enough to: 1) cause anyone any worry. 2) bother engineering a complicated compromise solution. If someone wants to argue that we still try to make it happen, I'll hear that and implement it if a consensus is formed. (FWIW, personally I'm still all for it). I tend to align with Ralph on this. I do think there is interest and even benefit from having a badge system coupled with the elections. If only because we have 2436 (on Thu Sep 12 13:56:25 UTC 2013) people registered on badges while for the last elections we had: - FESCO: 200 ballots - Board: 204 ballots Ah, got my number wrong, I must had found an older elections In June 2013 we announce results for Board, FESCo and FAmSCo: - Board: 157 ballots - FESCo: 166 ballots - FAmSCo: 175 ballots source: https://lists.fedoraproject.org/pipermail/announce/2013-June/003166.html And this month, for the F20 release name: 361 ballots source: https://lists.fedoraproject.org/pipermail/announce/2013-September/003181.html Point still stands though. There is the risk of having people voting just to get the badges, but there is also the possibility of motivating people to follow the elections and vote thanks to the badge system. However, the discussion here seems to indicate that a number of person do not like the idea of been marked as Has voted (w/o any other information) and unless more people express their opinion, then so be it :) My 2 cts, Pierre -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct pgpCSqSnBEGAP.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Proposal: AppData files in all application packages?
On Wed, Sep 11, 2013 at 10:28 PM, Dennis Gilmore den...@ausil.us wrote: El Wed, 11 Sep 2013 14:35:34 -0400 Matthias Clasen mcla...@redhat.com escribió: On Wed, 2013-09-11 at 12:46 -0500, Dennis Gilmore wrote: Any questions, either grab me on irc 'hughsie' or reply to this email. Be sure to read [1] as a lot of common questions are answered there. I have one question, if the data is shipped in the packages how is it supposed to get to the end user so that they can know about it and choose to install the application? We plan to extract it in the build system and provide it separate from the applications in the repository. that is very vague and handwavy, who is we? how exactly would it be provided to the user? https://fedorahosted.org/rel-eng/ticket/5721 I guess that by we, Matthias means people who are interested in gnome-software. Right now I think this includes (at least) Richard, Matthias, and I. We have some scripts that extract the relevant metadata from packages. https://github.com/hughsie/fedora-appstream/ We want the metadata to live with the rest of the repository metadata. gnome-software or packagekit or any other relevant component would download it and cache it locally. Legal approved: https://lists.fedoraproject.org/pipermail/legal/2013-September/002232.html Dennis -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- -Elad Alfassa. -- 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: [linux-sunxi] Re: Announcing Fedora 19 ARM remix for Allwinner SOCs release 1, now with A20 support
Hi, On 09/12/2013 04:27 PM, hmandevt...@gmail.com wrote: Hi Hans, i tryed to use your fedora 19 remix on my Olinuxino A20 Rev.D but don't start, there is only red and green leds power on static (no blink) but i have always hdmi signal off (i verified that script is for hdmi). Have you tried hooking up the uart to a serial port / usb - serial convertor too see if there are any kernel boot messages? Various people have been successfully using the image with hdmi out on the Olinuxino A20 Rev.D, without any issues. How are you powering the board ? Note that the board has an onboard regulator, so it needs 6V as a minimum input voltage. Also try replacing the sdcard and the hdmi cable. If that all fails, try another Linux distro, ie olimex's official images, if that fails too, it could be your board is broken. Regards, Hans -- 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 Path-Tiny-0.033.tar.gz uploaded to lookaside cache by pghmcfc
A file has been added to the lookaside cache for perl-Path-Tiny: cb70291b1792998c4780eced3ca4d20a Path-Tiny-0.033.tar.gz -- 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: BlueZ Status in Fedora.
Current status update for MATE. 1. Creating an applet for using gnome-bluetooth inside MATE is a death project for me. The applet himself is working (thanks kalev), but using gnome-blutooth properties is a problem since 'properties' isn't a standalone application anymore and moved to control-center. In result a user needs to install control-center and deps which is totally worse. 2. after vacation time MATE upstream has decided to port mate-bluetooth to bluez5 which will come for MATE-1.8 maybe and of the year or later. This means for f20 MATE won't support bluetooth. We will obsolete mate-bluetooth for the moment to avoid bug reports about this and re-activate it if it is ported to bluez5 during the release cycle of f20 and for f21. 3. A user of MATE desktop can use bluedevil from KDE for f20, which seems to be well working inside MATE. Bluedevil has also a systray applet. It would be very nice to mention this in f20 release notes. 4. From my personal side i won't block bluez5 for f20 Wolfgang -- 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: Review swaps: xfoil, xrotor, avl
On 12.09.2013 19:45, Antonio Trande wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 09/12/2013 07:37 PM, Sandro Mani wrote: Hi, I've posted the following package review requests: - #1007539 - xfoil: Subsonic Airfoil Development System - #1007540 - rotor: Design and analysis tools for propellers and windmills - #1007541 - avl: Aerodynamic and flight-dynamic analysis of rigid aircrafts They are all fortran/C applications with dead simple spec files (and beautiful handwritten Makefiles *cough*). Happy to review packages in exchange. Thanks, Sandro Hi Sandro. They seem me three software very old. Are you sure they are still under development ? Hi Antonio, xfoil was last updated 2008, xrotor in 2011 and avl in 2012. But regardless of this, xfoil in particular is widely used at universities and other people in the scientific community. Actually, its age is a sign that the program has been validated against a large number of testcases and is widely accepted to be reliable. So they are definitely worth having! Sandro -- 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 requiring Xorg BackingStore true
On 09/11/2013 05:27 PM, Sandro Mani wrote: Well, yes, but it ought to work regardless of the xorg.conf setting, because that setting has been effectively hardwired to true for about six years now. I rewrote the backing store implementation to use Composite internally, which is always available, so we just blindly ignore the config setting and give you backing store if you ask for it. There may be bugs, I freely admit, but it's definitely meant to work. If it doesn't it's probably a bug in X and I'll fix it, so hook me up with test packages and I'll take a look. I've uploaded an x86_64 rpm here [1], the srpm is here [2]. ... [1] http://smani.fedorapeople.org/xfoil-6.97-1.fc21.x86_64.rpm [2] http://smani.fedorapeople.org/xfoil-6.97-1.fc21.src.rpm [3] http://smani.fedorapeople.org/Naca63412.dat I compiled the RPM from your source on F19/x86_64 with an Xeon E3-1200 v2/3rd Gen using the intel driver (Ivybridge GT2). As ajax was saying, the window exposes work just fine: I can raise other windows on top of xfoil and when I re-expose xfoil it redraws properly. -- 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: Review swaps: xfoil, xrotor, avl
Okay. So I'll take those newly updated: avl and xrotor. Thanks Antonio, let me know if I can review anything in exchange. Btw, you will notice that they are all very similar, so if you manage those two, xfoil should be just as easy ;) Sandro -- 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: I am thinking of adding compression to libselinux
On Thu, Sep 12, 2013 at 09:16:13AM -0400, Matthew Miller wrote: On Thu, Sep 12, 2013 at 02:11:04PM +0200, Lennart Poettering wrote: (That said, our minimal image is a couple of 100mb still, iirc, so 2mb is not tht much.) It's basically down to the three big unsolved problems (kernel modules, translations, docs) and then several dozen little things like this. If getting really small is a priority we need to solve the big problems, but chipping away at the little things helps too. Lots of distros are now gzip- or xz-compressing kernel modules. That's the reason for the code I just posted elsewhere in this thread. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming blog: http://rwmj.wordpress.com Fedora now supports 80 OCaml packages (the OPEN alternative to F#) -- 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 requiring Xorg BackingStore true
On 12.09.2013 21:30, Przemek Klosowski wrote: On 09/11/2013 05:27 PM, Sandro Mani wrote: Well, yes, but it ought to work regardless of the xorg.conf setting, because that setting has been effectively hardwired to true for about six years now. I rewrote the backing store implementation to use Composite internally, which is always available, so we just blindly ignore the config setting and give you backing store if you ask for it. There may be bugs, I freely admit, but it's definitely meant to work. If it doesn't it's probably a bug in X and I'll fix it, so hook me up with test packages and I'll take a look. I've uploaded an x86_64 rpm here [1], the srpm is here [2]. ... [1] http://smani.fedorapeople.org/xfoil-6.97-1.fc21.x86_64.rpm [2] http://smani.fedorapeople.org/xfoil-6.97-1.fc21.src.rpm [3] http://smani.fedorapeople.org/Naca63412.dat I compiled the RPM from your source on F19/x86_64 with an Xeon E3-1200 v2/3rd Gen using the intel driver (Ivybridge GT2). As ajax was saying, the window exposes work just fine: I can raise other windows on top of xfoil and when I re-expose xfoil it redraws properly. You likely have a compositing window manager running? Cause it definitely did not work with kwin with compositing turned off. Anyway, ajax has posted patches for this to the xorg-devel list [1]. And btw, I've now posted a review request for xfoil [2] with a polished srpm, in case you are interested. Sandro [1] http://lists.x.org/archives/xorg-devel/2013-September/037773.html [2] https://bugzilla.redhat.com/show_bug.cgi?id=1007539 -- 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: Review swaps: xfoil, xrotor, avl
On 12.09.2013 22:05, Brendan Jones wrote: On 09/12/2013 09:36 PM, Sandro Mani wrote: Okay. So I'll take those newly updated: avl and xrotor. Thanks Antonio, let me know if I can review anything in exchange. Btw, you will notice that they are all very similar, so if you manage those two, xfoil should be just as easy ;) Sandro I can take it now for: https://bugzilla.redhat.com/show_bug.cgi?id=1003768 Let me know. cheers bsjones Sure, thanks! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: A fresh idea (was: fedmsg for voting?)
On Thu, Sep 12, 2013 at 11:22 AM, Ralph Bean rb...@redhat.com wrote: A fresh idea came up in #fedora-apps: What if we nix fedmsg for voting all together, but we supply a link in each election page: Claim the badge for voting that you can click to, well, get the badge. This way no tracking is done whatsoever and we can also give the I voted sticker to only people who want it. Best idea yet and you can change my -1 to a +1 for this. John -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Package name conflict with retired package
Hi, I just posted a review for avl (the Aerodynamic and flight-dynamic analysis of rigid aircrafts package) [1], and the reviewer noticed that it conflicts with the retired avl package (the AVL tree manipulation library). How should one proceed in such situations? Does the old repository needs to be deleted before the new one is created? Thanks, Sandro [1] https://bugzilla.redhat.com/show_bug.cgi?id=1007541 [2] http://pkgs.fedoraproject.org/cgit/avl.git/ -- 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 requiring Xorg BackingStore true
On 12.09.2013 16:41, Adam Jackson wrote: On Wed, 2013-09-11 at 23:27 +0200, Sandro Mani wrote: Well, yes, but it ought to work regardless of the xorg.conf setting, because that setting has been effectively hardwired to true for about six years now. I rewrote the backing store implementation to use Composite internally, which is always available, so we just blindly ignore the config setting and give you backing store if you ask for it. There may be bugs, I freely admit, but it's definitely meant to work. If it doesn't it's probably a bug in X and I'll fix it, so hook me up with test packages and I'll take a look. I've uploaded an x86_64 rpm here [1], the srpm is here [2]. To reproduce the problem, first download the foil gometry [3], then run xfoil from a terminal, and type load Naca63412.dat and at the following Enter airfoil name prompt, type naca63412 Upon pressing enter, the Xplot11 window should open, showing the cross-section of the foil. The Xlib code for the plotting window is in plotlib/Xwin.c in the xfoil source tarball. Oh my, this is embarassing. If only I'd deleted more code you'd never have hit this. Definitely a bug in xserver. I'll send a patch upstream and fix Fedora once that lands. Thanks for the testcase! Awesome, 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
[perl-MIME-Types] Update to 2.04
commit e55456b29e21fff5b931922da63f21646fbcca76
Author: Paul Howarth p...@city-fan.org
Date: Thu Sep 12 15:46:18 2013 +0100
Update to 2.04
- New upstream release 2.04:
- Fix one more localize $_ in ::Types::_read_db() (CPAN RT#87856)
perl-MIME-Types.spec |6 +-
sources |2 +-
2 files changed, 6 insertions(+), 2 deletions(-)
---
diff --git a/perl-MIME-Types.spec b/perl-MIME-Types.spec
index 86b0267..0ddbe35 100644
--- a/perl-MIME-Types.spec
+++ b/perl-MIME-Types.spec
@@ -1,5 +1,5 @@
Name: perl-MIME-Types
-Version:2.03
+Version:2.04
Release:1%{?dist}
Summary:MIME types module for Perl
License:GPL+ or Artistic
@@ -55,6 +55,10 @@ rm -rf %{buildroot}
%{_mandir}/man3/MIME::Types.3pm*
%changelog
+* Thu Sep 12 2013 Paul Howarth p...@city-fan.org - 2.04-1
+- Update to 2.04:
+ - Fix one more localize $_ in ::Types::_read_db() (CPAN RT#87856)
+
* Wed Sep 4 2013 Paul Howarth p...@city-fan.org - 2.03-1
- Update to 2.03:
- Fix typo in docs (CPAN RT#88394)
diff --git a/sources b/sources
index c00f2a4..a906d66 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-90a0970063b4756429046de561432bdc MIME-Types-2.03.tar.gz
+e292bbf7756bb4999407f3f660697168 MIME-Types-2.04.tar.gz
--
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: Firewall blocking desktop features
Am 11.09.2013 23:18, schrieb Mateusz Marzantowicz: On 11.09.2013 17:24, Daniel J Walsh wrote: On 09/11/2013 09:18 AM, Reindl Harald wrote: The problem with this solution is potential conflicts in port numbers and pps that just use random ports (Which I think should just not be allowed to use the service and would require to disable the firewall.) the real problem i described above as long the is no way to get *predictable* which service/process is aksing for open a specific port and verify this on the system level this all is completly pointless Interesting discussion but several things doesn't fit together for me: 1. It's firewall's job to manage and keep track of opened ports and established connection so it also should be the piece of software that asks user if he wants to allow network traffic or not. yes 2. Why you say there is no way for firewall to know which app is requesting specific port to be opened? There is a process name and path and it could be identified. could - well, could is not a working implementation show a working implementation firewall means iptables yes, firewalld is nothing else than writing netfilter rules) It's also easy to maintain database of most commonly used binaries and ports that they'd like to open/close. If you don't trust binaries on your system it means it's already been compromised and firewall is then useless in case of *desktop features* most of the time you are speaking about not so well known ports like 80,443,445 and what i fight against is the proposal someone brought in this thread is that the *application defines* the message which the user confirms to open a port - from security point of view this is the most stupid way to go and will later end in a nightmare 3. If you allow each app to ask for permission to open some port, it'll certainly be done in thousand different ways and lack of consistency isn't going to help users *what*? where do i say anything about 1000 different ways? the *opposite* is what i claim all the time must happen and what most people do not realize here is that the whole system (netfilter, network stack, applications) need to work tight together in the case of a request because the application layer still sends data and you have to consider queue packets and after open the firewall send them to the application or whatever you liked to do likely will fail so with the current state of play there is a lot of infrastructure missing for even loudly consider to implement desktop firewalls as knwon from the windows world and honestly before there are done mistakes i clearly say do not touch it at all simply because it worked over decades, it is still working and before now one comes out and says but not comfortable enough he should take a breath and realize that if it comes to security it works *always* against of comfort with *no* exceptions at all 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: fedmsg for voting?
On Thu, Sep 12, 2013 at 7:59 AM, Ralph Bean rb...@redhat.com wrote: On Wed, Sep 11, 2013 at 09:23:44PM -0700, Toshio Kuratomi wrote: On Sep 11, 2013 6:02 PM, Matthew Miller mat...@fedoraproject.org wrote: What if we made this like the I voted stickers -- you can get one by checking a box in the voting app? (Even if, by the way, you cast no actual votes?) I had thought that this would trigger off of someone hitting submit on the election page. That should vote 0 for all candidates if no votes are assigned but still meet the trigger condition. Not sure if that meets the criteria for objectors, though. Ralph bean should weigh in here as to whether logged in during an election period would also be suitable (which was something that people seemed to think would be acceptable earlier in the thread). Hm, its not worth doing if we're going to make it complex like this. I think we should just drop it. No fedmsg broadcast for votes, only for election period opening/closing and only for election results publication/retraction by the admin (with obviously no user participation data included). It is just not important enough to: 1) cause anyone any worry. 2) bother engineering a complicated compromise solution. If someone wants to argue that we still try to make it happen, I'll hear that and implement it if a consensus is formed. (FWIW, personally I'm still all for it). I thought triggering off logging into the election app would be easier and at least in my case is a compromise that I would be comfortable with even without any opt-in/opt-out addition beyond what you have already made available globally. John -- 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 20-Alpha RC2 AMIS
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 hi all, RC2 images have been uploaded to EC2 and are available at ami-1bb5fc72 : us-east-1 image for i386 ami-03c8816a : us-east-1 image for x86_64 additionally if your looking to the AMI's they have been added to files in the release tree http://dl.fedoraproject.org/pub/alt/stage/20-Alpha-RC2/Images/i386/Fedora-Images-i386-20-Alpha-AMI http://dl.fedoraproject.org/pub/alt/stage/20-Alpha-RC2/Images/x86_64/Fedora-Images-x86_64-20-Alpha-AMI when we get to final alpha and the images are uploaded to all regions they will all be listed and the file will be signed in the final tree Dennis -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.21 (GNU/Linux) iEYEARECAAYFAlIyNi8ACgkQkSxm47BaWfe9YgCeO2tq49n17jUtlmQY0uL90RK/ GPAAoMGvNSgVZUR4kY9pR2IMZPKFjmbz =jOXf -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: numatop: %{optflags} fail the 32bit build
On Wed, Sep 11, 2013 at 08:46:33AM +0200, Florian Weimer wrote:
This is the offending function:
void
cpuid(unsigned int *eax, unsigned int *ebx, unsigned int *ecx,
unsigned int *edx)
{
__asm volatile
(cpuid\n\t
: =a (*eax),
=b (*ebx),
=c (*ecx),
=d (*edx)
: a (*eax));
}
The cryptic GCC error message (inconsistent operand constraints in
an ‘asm’) refers to the fact that in PIC mode (which is activated
by the hardening flags), %ebx is a reserved register.
This version should work in 32 bit mode, and only in 32 bit mode:
void
cpuid(unsigned int *eax, unsigned int *ebx, unsigned int *ecx,
unsigned int *edx)
{
__asm volatile
(push %%ebx\n\t
cpuid\n\t
mov %%ebx, (%1)\n\t
pop %%ebx
: =a (*eax),
=S (ebx),
=c (*ecx),
=d (*edx)
: 0 (*eax));
}
I have not actually tested this. There are other solutions
floating around, but they are clearly incorrect and produce wrong
code.
A better fix would be to rip all this out, and use reads from
/dev/cpu/*/cpuid, which is arch agnostic, and also takes care of cpu affinity
problems.
Dave
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: fedmsg for voting?
On Thu, Sep 12, 2013 at 09:55:51AM -0500, inode0 wrote: On Thu, Sep 12, 2013 at 7:59 AM, Ralph Bean rb...@redhat.com wrote: On Wed, Sep 11, 2013 at 09:23:44PM -0700, Toshio Kuratomi wrote: On Sep 11, 2013 6:02 PM, Matthew Miller mat...@fedoraproject.org wrote: What if we made this like the I voted stickers -- you can get one by checking a box in the voting app? (Even if, by the way, you cast no actual votes?) I had thought that this would trigger off of someone hitting submit on the election page. That should vote 0 for all candidates if no votes are assigned but still meet the trigger condition. Not sure if that meets the criteria for objectors, though. Ralph bean should weigh in here as to whether logged in during an election period would also be suitable (which was something that people seemed to think would be acceptable earlier in the thread). Hm, its not worth doing if we're going to make it complex like this. I think we should just drop it. No fedmsg broadcast for votes, only for election period opening/closing and only for election results publication/retraction by the admin (with obviously no user participation data included). It is just not important enough to: 1) cause anyone any worry. 2) bother engineering a complicated compromise solution. If someone wants to argue that we still try to make it happen, I'll hear that and implement it if a consensus is formed. (FWIW, personally I'm still all for it). I thought triggering off logging into the election app would be easier and at least in my case is a compromise that I would be comfortable with even without any opt-in/opt-out addition beyond what you have already made available globally. It needs to be something else than logging in, maybe, visit the vote page logged in. That should be easy enough to do in nuancier-lite (and we'll see about elections). Works for me :) Pierre -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: I am thinking of adding compression to libselinux
Richard W.M. Jones (rjo...@redhat.com) said: On Thu, Sep 12, 2013 at 09:16:13AM -0400, Matthew Miller wrote: On Thu, Sep 12, 2013 at 02:11:04PM +0200, Lennart Poettering wrote: (That said, our minimal image is a couple of 100mb still, iirc, so 2mb is not tht much.) It's basically down to the three big unsolved problems (kernel modules, translations, docs) and then several dozen little things like this. If getting really small is a priority we need to solve the big problems, but chipping away at the little things helps too. Lots of distros are now gzip- or xz-compressing kernel modules. That's the reason for the code I just posted elsewhere in this thread. I believe the issue is not that the kernel modules are uncompressed, it's that there are so many of them that are completely irrelevant in cloud/virt scenarios. Bill -- 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 Alpha to slip by one week
Today at Go/No-Go meeting it was decided to slip Fedora 20 Alpha release by one week due to two unresolved blocker bugs, see the blocker tracking app [1]. Otherwise we think we have pretty solid foundation for Alpha. More details in meeting minutes [2]. As a result, ALL MAJOR MILESTONES, and their dependent tasks, will be pushed out by one week [3]. The next Go/No-Go meeting is on Thursday, Sep 19, the same time but due to possible conflict with FPC meeting we will move to #fedora-meeting-2 channel. [1] http://qa.fedoraproject.org/blockerbugs/milestone/20/alpha/buglist [2] http://meetbot.fedoraproject.org/fedora-meeting-2/2013-09-12/f20_alpha_gono-go_meeting.2013-09-12-17.03.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
Re: A fresh idea (was: fedmsg for voting?)
+1 El jue, 12-09-2013 a las 15:10 -0500, inode0 escribió: On Thu, Sep 12, 2013 at 11:22 AM, Ralph Bean rb...@redhat.com wrote: A fresh idea came up in #fedora-apps: What if we nix fedmsg for voting all together, but we supply a link in each election page: Claim the badge for voting that you can click to, well, get the badge. This way no tracking is done whatsoever and we can also give the I voted sticker to only people who want it. Best idea yet and you can change my -1 to a +1 for this. John -- 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: Review swaps: xfoil, xrotor, avl
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 09/12/2013 08:32 PM, Sandro Mani wrote: On 12.09.2013 19:45, Antonio Trande wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 09/12/2013 07:37 PM, Sandro Mani wrote: Hi, I've posted the following package review requests: - #1007539 - xfoil: Subsonic Airfoil Development System - #1007540 - rotor: Design and analysis tools for propellers and windmills - #1007541 - avl: Aerodynamic and flight-dynamic analysis of rigid aircrafts They are all fortran/C applications with dead simple spec files (and beautiful handwritten Makefiles *cough*). Happy to review packages in exchange. Thanks, Sandro Hi Sandro. They seem me three software very old. Are you sure they are still under development ? Hi Antonio, xfoil was last updated 2008, xrotor in 2011 and avl in 2012. But regardless of this, xfoil in particular is widely used at universities and other people in the scientific community. Actually, its age is a sign that the program has been validated against a large number of testcases and is widely accepted to be reliable. So they are definitely worth having! Okay. So I'll take those newly updated: avl and xrotor. - -- - Antonio Trande mailto: sagit...@fedoraproject.org http://www.fedoraos.worpress.com https://fedoraproject.org/wiki/User:Sagitter GPG Key: D400D6C4 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.14 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSMg8WAAoJED2vIvfUANbE9VgQAIQ75g+hpAKYgxl9U2Y6bi6h zCbTNhHKEyxnRq00mcwSH/rvLgBWHw3M3NBYq+0gXtF6XivqLBAY0KCk7My3Ix2L sEIgVUUp3mv3ZC8pdp+rLLBI27+voVaqPu3Dpoj5/Ly4oMr3g5fLnJ0TNAQ2F/WT Re97/hYHpXM9aip5j7+uzFOrYrVeyrVcLvMUS3JCY1YYvX0DQ7F/xkS0Z9haDnv9 SW1OqyWeLvH/r+vmDza/sUQLuw6TJC7V4RahQSdKRvBM5GaBmVnzlLiwh8lPS+ol ZueYUifQ+eORDkOlKl5V2XQsUyxRvdOJCIgReMofYJ9aDCAFvQuvURMqgaDV4DNn U3KEZzfkcgjGvVXYb8Lk8GsziFBvZa00mxwDZWo5a0ROyv1wK2bg+UwXkM/6rFcE CyShviIVdymxPEoJMPs3XsbPnC1JvgsALQduDoKQ42oaAYP0fs74HZt8edDmmhv5 EX/BnlQzGzdGTQnll15Ki7w8gMSGYeichRsoMJyiKlWPoYtaP01PuSt0hw/XmS9V CDPo7eMuRzJGhoJeFXiLClpQqKhztdfcbh6hzub8LA+3z4Ebah0yR58AdGIlYgd5 EElMu41Qo+ZzaJwguax8ekwrypeHRrLLP6X5Xm8CNOtGU7oAoDP/A9iLhrDpH3KP Ruy+p4gytHa76V+YKXnw =ol0U -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: Firewall blocking desktop features
Am 12.09.2013 08:25, schrieb Pierre-Yves Chibon: Application should request the ports to be opened and the firewalld layer should then confirm with the user stating which ports and which app requested said ports. The app can't lie if the firewall layer is the one asking for confirmation. But a malicious app can pretend to be another one, unless there is a way for the firewall to know which app is asking in a way that cannot be forged the problem is that people refuse to understand security implications until it is too late and in context of a firewall this is fatal proven by 80 out of 100 alerts on securityfocus for *any* sort of software and before someone comes out with but konqueror is from a package well, and you be 100% sure that you not treat /usr/local/bin/ or ~/bin/konqueror the same trusted way and how do you make it sure? 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: Proposal: AppData files in all application packages?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 El Thu, 12 Sep 2013 16:47:13 +0200 Elad Alfassa e...@fedoraproject.org escribió: On Wed, Sep 11, 2013 at 10:28 PM, Dennis Gilmore den...@ausil.us wrote: El Wed, 11 Sep 2013 14:35:34 -0400 Matthias Clasen mcla...@redhat.com escribió: On Wed, 2013-09-11 at 12:46 -0500, Dennis Gilmore wrote: Any questions, either grab me on irc 'hughsie' or reply to this email. Be sure to read [1] as a lot of common questions are answered there. I have one question, if the data is shipped in the packages how is it supposed to get to the end user so that they can know about it and choose to install the application? We plan to extract it in the build system and provide it separate from the applications in the repository. that is very vague and handwavy, who is we? how exactly would it be provided to the user? https://fedorahosted.org/rel-eng/ticket/5721 I guess that by we, Matthias means people who are interested in gnome-software. Right now I think this includes (at least) Richard, Matthias, and I. We have some scripts that extract the relevant metadata from packages. https://github.com/hughsie/fedora-appstream/ We want the metadata to live with the rest of the repository metadata. gnome-software or packagekit or any other relevant component would download it and cache it locally. Legal approved: https://lists.fedoraproject.org/pipermail/legal/2013-September/002232.html So I am confused. In your request to legal you say Release Engineering asked for legal to okay it. However I dont remember ever asking you to get legal's okay. Who in releng asked you to? I really do not think we can integrate this into our release processes right now. Dennis -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.21 (GNU/Linux) iEYEARECAAYFAlIyQqYACgkQkSxm47BaWfetoACeNy3lAAFdl1nlmlICmwZcQn+2 xrcAoL3+etmYfOGD1qN7TC5530pd0IVO =8t+m -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: Firewall blocking desktop features
On Thursday 12 September 2013 09:23:13 Colin Walters wrote: On Thu, 2013-09-12 at 10:01 +0300, Oron Peled wrote: * From pid you can find the real executable (/proc/pid/cmd). And this is the step that's worthless: https://bugzilla.gnome.org/show_bug.cgi?id=533493 Thanks, that was a very good read. However, there may be still way out for some cases... * First, let's talk about the primary mentioned attack vector -- LD_PRELOAD/ptrace attacks: - These should be ignored by suid/sgid binaries on modern Linux systems (sans kernel bugs). - So if we can sgid all these binaries to a specific group -- this threat is mitigated. - Actually, with this, the service can simply talk to clients running in this firewalld-control group. - Obviously, SELinux (which was mentioned in the URL) is a better solution along the same lines (labeling), but I think it wouldn't be easy to upstream a solution that can only work with SELinux. * But thinking more about attack vectors, I got a more depressing picture: - Assume a valid UI controller get subverted *during* run-time. - Examples: a buffer overrun, dlopen() malicious plugin, loading other dynamic code (e.g: via embedded python interpreter), etc. - This looks pretty hopeless to me in any case (be it SELinux or what's-not) As the same trusted process instantly becomes a bad-guy. - This isn't very different than a hypothetical security hole in ssh that would enable attacker to steal my private key. - *BUT*, since typical GUI programs are far bigger than ssh (including the whole UI library stacks), the risks for buffer overruns are not marginal. - This means that any privileged service controlled by GUI client (e.g: NetworkManager) is still only as secure as it's controller (e.g: nm-applet). - It's true that this is somewhat better than the old suid-root GUI wrappers that could do *anything* to your system. But still, we have no idea how to protect system-wide services *if* they need GUI control. - Or am I missing something here? -- Oron Peled Voice: +972-4-8228492 o...@actcom.co.il http://users.actcom.co.il/~oron Your fair use of this book is restricted You may only read this book once -- 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: Review swaps: xfoil, xrotor, avl
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 09/12/2013 09:36 PM, Sandro Mani wrote: Okay. So I'll take those newly updated: avl and xrotor. Thanks Antonio, let me know if I can review anything in exchange. https://bugzilla.redhat.com/show_bug.cgi?id=1002251 ;) Btw, you will notice that they are all very similar, so if you manage those two, xfoil should be just as easy ;) In the near future. - -- - Antonio Trande mailto: sagit...@fedoraproject.org http://www.fedoraos.worpress.com https://fedoraproject.org/wiki/User:Sagitter GPG Key: D400D6C4 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.14 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSMhuSAAoJED2vIvfUANbEjJsP/jSOt7nUs2M+wtxRCScFSofC re0ShwmCw6wN+hFwQBT04jFL/4vm/t0Z3DWKqydz/7b5uFy+rv90XnNdn2ikQJ/0 dZljugq+0Km2ju0h1I9hx2RDLTdZyIR4R+vEb/ygNcO1VAbu5ciIZd006S65190E pqvBWPGsNGzYQhQwuCh+NM2wtF8py9mdIHt2r/XmG8As0nlEuj79tGQM3XvwxlAz IXkJNHgzgXliMCX43g+Ay2y1R5q9CLSmwE04hh9OzmGGgRJZ/IeoMhTxMs7pH+CF 5C259JS4DrCA9OwVOyphSnNL1+Nv17xdV9lsLvJ9PjoJO4Tijw3kFmEkaXS9YKZx sRDdXQzbDrTFdb0uu97uuwhEjRWXagUN6BjolOwKh2qM8WPqtR5ldq2xG7oPrX5u D278oK3VnhKkiKr0yDVTebIB8bNew2u1Z0si0LfSOwRykbybYBoibiQsPkJEHWCK yHrRPq0u09oGMPtegPAEJpKBWxskfoEGKIGZt5gFKA6Arp8Tk5z3jdg4bVOxFe3H yp/lNJg8pmRw0J8kKPpqryuz/L5Brf58LAG439Xg0bUUubqf5ytvMm5Qa/ueHgJc Y9tf60q0u2O+iiVCFZs5wiGGbXYeFeQ6ZTFFVj6EfL0tQv58NOY0W/T70BNSUfwh FOqH4vjSTdwHASewHCbd =GgwV -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
A fresh idea (was: fedmsg for voting?)
On Thu, Sep 12, 2013 at 05:30:43PM +0200, Pierre-Yves Chibon wrote: On Thu, Sep 12, 2013 at 09:55:51AM -0500, inode0 wrote: On Thu, Sep 12, 2013 at 7:59 AM, Ralph Bean rb...@redhat.com wrote: Hm, its not worth doing if we're going to make it complex like this. I think we should just drop it. No fedmsg broadcast for votes, only for election period opening/closing and only for election results publication/retraction by the admin (with obviously no user participation data included). It is just not important enough to: 1) cause anyone any worry. 2) bother engineering a complicated compromise solution. If someone wants to argue that we still try to make it happen, I'll hear that and implement it if a consensus is formed. (FWIW, personally I'm still all for it). I thought triggering off logging into the election app would be easier and at least in my case is a compromise that I would be comfortable with even without any opt-in/opt-out addition beyond what you have already made available globally. It needs to be something else than logging in, maybe, visit the vote page logged in. That should be easy enough to do in nuancier-lite (and we'll see about elections). Works for me :) A fresh idea came up in #fedora-apps: What if we nix fedmsg for voting all together, but we supply a link in each election page: Claim the badge for voting that you can click to, well, get the badge. This way no tracking is done whatsoever and we can also give the I voted sticker to only people who want it. pgpdgg987WX3i.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Review swap: xflr5
Hi, One more airfoil package: #1007604 - xflr5: Analysis tool for airfoils, wings and planes C++/Qt code with simple qmake build and desktop file. Again, happy to review in exchange. Thanks, Sandro -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Review swaps: xfoil, xrotor, avl
Hi, I've posted the following package review requests: - #1007539 - xfoil: Subsonic Airfoil Development System - #1007540 - rotor: Design and analysis tools for propellers and windmills - #1007541 - avl: Aerodynamic and flight-dynamic analysis of rigid aircrafts They are all fortran/C applications with dead simple spec files (and beautiful handwritten Makefiles *cough*). Happy to review packages in exchange. Thanks, Sandro -- 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: Firewall blocking desktop features
On Fri, Sep 13, 2013 at 1:26 AM, Oron Peled o...@actcom.co.il wrote: - This means that any privileged service controlled by GUI client (e.g: NetworkManager) is still only as secure as it's controller (e.g: nm-applet). This is wrong. That's not how controlling the service works. -- 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: I am thinking of adding compression to libselinux
On Thu, Sep 12, 2013 at 07:53:30AM -0400, Daniel J Walsh wrote: Basically looking at compressing the policy file to shrink SELinux footprint in the minimal install/cloud image. Currently the policy modules (pp files) are shipped with bzip compression but the actually policy file. But the /etc/selinux/targeted/policy/policy.29 is not compressed. systemd and load_policy use libselinux to read in the policy file and load it into the kernel, so since systemd currently uses libxz, I figured this would be the best solution to add libxz support to libselinux. This example code may be helpful. It loads a file that may be gzip or lzma (xz) compressed into memory: https://github.com/libguestfs/supermin/blob/master/helper/init.c#L284 Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-df lists disk usage of guests without needing to install any software inside the virtual machine. Supports Linux and Windows. http://people.redhat.com/~rjones/virt-df/ -- 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-MIME-Types/f20] Update to 2.04
Summary of changes: e55456b... Update to 2.04 (*) (*) This commit already existed in another branch; no separate mail sent -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: Review swaps: xfoil, xrotor, avl
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 09/12/2013 07:37 PM, Sandro Mani wrote: Hi, I've posted the following package review requests: - #1007539 - xfoil: Subsonic Airfoil Development System - #1007540 - rotor: Design and analysis tools for propellers and windmills - #1007541 - avl: Aerodynamic and flight-dynamic analysis of rigid aircrafts They are all fortran/C applications with dead simple spec files (and beautiful handwritten Makefiles *cough*). Happy to review packages in exchange. Thanks, Sandro Hi Sandro. They seem me three software very old. Are you sure they are still under development ? - -- - Antonio Trande mailto: sagit...@fedoraproject.org http://www.fedoraos.worpress.com https://fedoraproject.org/wiki/User:Sagitter GPG Key: D400D6C4 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.14 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSMf2zAAoJED2vIvfUANbEhNgP/2nrYX7ZOkmfvh40I+S1ACB1 iAdIfWm/BMrpdPiBsNLMRAIF7TR0KgbNLofU21ohbqGCAyAW+xK4shPnFrqyisYa +IsGERkjoZZNhxukOQub1fE3YULR/VFCjvp5YEBfRBwKgruRyRNV/WQkbmd82KGq uP7ogWMsT7O+U/EIT0EZbtEItUOo+xnq4JBwkeHv7Td8j5P0RxdI2DKxe7taA14a /hROLNxnH1dJY8o/vfmNTU4zIVS/tQHdOJgv1ibc7llKbG6zDBaRi8UOIXQH6eEr O9zBcSf0HDCL2GMttZJQvAGy9E4YJ6Ce1VisViHyJsNn7HUtMWydf0nkEDWQqGHx KK8oowMBUrm4TkU7y+b4arFJMO+VNX6lLdNG2mA4C2Z87xT6XiqIb+5vavzQkqqS 5mT3aXoIVB3GHBEe9HlQYWdPgEOgmA8NcpiHL4Mn35cadvroRI4dIsoE69HZ6UPh YFIPnjKfRBA5qIci5XytrHjsVpL9nv7XurNH8O5YSWhp/+Uo+xngWq5cMRBoqWUq FxUkVI8yf6rW+d4apobcEFBRIzG5CNTrzvkOx3ON9ANmrqrHDHd1mCVKc0Rz9zet GBLtWxk4FFs0kMfJ4N838trt7AtGY6vBUn17sYaTqHdasuqqv0GaCBZhkOZ3juiq 7NGmC+90lieLiRLrJzQd =AiXd -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: Protection from merge commits
On Thu, Sep 12, 2013 at 10:37:44 +0100, David Howells dhowe...@redhat.com wrote: I presume that that would prevent valid merging between branches in the repo? For example, I have a reasonably simple package that I apply patches to in the master branch and then merge everything back into the last few Fedora version branches. Usually merge just fast-forwards the branch, but occasionally there has been a mass-rebuild that threw an extra commit in that then needs dealing with. I presume I would then need to pick all the commits instead? I think in that case you'd do a rebase. -- 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: Review swaps: xfoil, xrotor, avl
On 09/12/2013 09:36 PM, Sandro Mani wrote: Okay. So I'll take those newly updated: avl and xrotor. Thanks Antonio, let me know if I can review anything in exchange. Btw, you will notice that they are all very similar, so if you manage those two, xfoil should be just as easy ;) Sandro I can take it now for: https://bugzilla.redhat.com/show_bug.cgi?id=1003768 Let me know. cheers bsjones -- 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 20-Alpha RC2 AMIS
On Thu, Sep 12, 2013 at 04:46:17PM -0500, Dennis Gilmore wrote: ami-1bb5fc72 : us-east-1 image for i386 This still doesn't boot. (We're working on it.) -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Fedora Policy Index
Hi, Here goes a dumb question: Where is the listing of all (active) fedora policies located? I am looking specifically for the greeter (gdm/kmd/etc) policy. Thanks in advance. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
[Bug 1007199] perl segfaults when pushing a glob to a thread-shared array
https://bugzilla.redhat.com/show_bug.cgi?id=1007199 Petr Pisar ppi...@redhat.com changed: What|Removed |Added Summary|perl segfaults when pushing |perl segfaults when pushing |a glob to thread-shared |a glob to a thread-shared |array |array -- 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=gp4hcQpI7da=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-Parallel-Scoreboard/f20] (2 commits) ...Upstream update.
Summary of changes: a89716f... Upstream update. (*) 313b32a... Upstream update. (*) (*) 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
[perl-Parallel-Scoreboard/f19: 6/6] Merge cleanup.
commit 7c43e5e3d424b4fe378684b47c19ee22c2f94d20 Author: Ralf Corsépius corse...@fedoraproject.org Date: Thu Sep 12 10:31:52 2013 +0200 Merge cleanup. perl-Parallel-Scoreboard.spec |3 --- 1 files changed, 0 insertions(+), 3 deletions(-) --- diff --git a/perl-Parallel-Scoreboard.spec b/perl-Parallel-Scoreboard.spec index 8091ab5..4a0d0e0 100644 --- a/perl-Parallel-Scoreboard.spec +++ b/perl-Parallel-Scoreboard.spec @@ -63,9 +63,6 @@ make test - Upstream update. - Modernize spec. -* Sun Aug 04 2013 Fedora Release Engineering rel-...@lists.fedoraproject.org - 0.03-10 -- Rebuilt for https://fedoraproject.org/wiki/Fedora_20_Mass_Rebuild - * Mon Jul 22 2013 Petr Pisar ppi...@redhat.com - 0.03-9 - Perl 5.18 rebuild - Remove bundled modules Test::Builder and Test::Builder::Module because they -- 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-Parallel-Scoreboard/f19] (6 commits) ...Merge cleanup.
Summary of changes: da55e44... Perl 5.18 rebuild (*) 46d5216... Remove bundled modules Test::Builder and Test::Builder::Mod (*) 7684dc3... - Rebuilt for https://fedoraproject.org/wiki/Fedora_20_Mass (*) a89716f... Upstream update. (*) 313b32a... Upstream update. (*) 7c43e5e... Merge cleanup. (*) 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
[Bug 1007313] New: perl-autodie-2.21 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1007313 Bug ID: 1007313 Summary: perl-autodie-2.21 is available Product: Fedora Version: rawhide Component: perl-autodie Keywords: FutureFeature, Triaged Assignee: ppi...@redhat.com Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: perl-devel@lists.fedoraproject.org, ppi...@redhat.com Latest upstream release: 2.21 Current version/release in Fedora Rawhide: 2.20-4.fc20 URL: http://search.cpan.org/dist/autodie/ 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=tnPX7RCsHQa=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 987397] perl-Plack-Middleware-Deflater-0.12 is available
https://bugzilla.redhat.com/show_bug.cgi?id=987397 Upstream Release Monitoring upstream-release-monitor...@fedoraproject.org changed: What|Removed |Added Summary|perl-Plack-Middleware-Defla |perl-Plack-Middleware-Defla |ter-0.11 is available |ter-0.12 is available --- Comment #2 from Upstream Release Monitoring upstream-release-monitor...@fedoraproject.org --- Latest upstream release: 0.12 Current version/release in Fedora Rawhide: 0.11-1.fc20 URL: http://search.cpan.org/dist/Plack-Middleware-Deflater/ 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=qsDXP0TNRSa=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
