Re: boost141 and stability of Boost API?
Upstream Tracker is a convenient place for checking API/ABI changes: For Boost: http://upstream-tracker.org/versions/boost.html -robin On Sun, Sep 29, 2013 at 11:44 AM, Dave Johansen wrote: > I just noticed that the boost141 package had been previously available in > Fedora, but it has since been removed ( > https://fedorahosted.org/rel-eng/ticket/5291 ). I'm not familiar with the > recent changes in Boost, but is the API stable enough to support a package > to build on EL 5/6 and Fedora? > Thanks, > 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 > -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
boost141 and stability of Boost API?
I just noticed that the boost141 package had been previously available in Fedora, but it has since been removed ( https://fedorahosted.org/rel-eng/ticket/5291 ). I'm not familiar with the recent changes in Boost, but is the API stable enough to support a package to build on EL 5/6 and Fedora? Thanks, 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: About F19 Firewall
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Sat, Sep 28, 2013 at 01:34:48PM +0200, Björn Persson wrote: > Eric H. Christensen wrote: > >> link-layer encryption like WPA2 won't protect anything anymore > > > >What do you think WPA2 protects against? It has never protected > >against anything but decoding of intercepted packets across the > >wireless link. > > As far as I know it's also supposed to prevent active attacks, not just > passive eavesdropping. The underlying assumption is that your local > wired network is protected by a firewall plus physical walls and locked > doors, and that you have something insecure on your network that needs > that protection. Then when you add a wireless link you have to prevent > others from connecting to it and attacking your insecure stuff. That's > what WPA2 is for. WiFi encryption only helps you against local attacks not anything on the Internet. Depending on your level of security of your networked devices it may or may not make any difference whether you are using encryption on the WiFi network itself (i.e. if you are sharing files across your network via SCP then no one listening in will be able to make heads or tails of the data anyway). And then there is the layer of authentication... If you are using insecure stuff then I'd probably have to tell you to stop that or otherwise block incoming requests at the gateway. It's really not that hard. > > But if your firewall is just a side effect of your NAT, and IPv6 makes > NAT obsolete, then your insecure stuff is no longer protected. I used to work for a place where everything had a public IP address on it. Don't want people coming to those machines from the Internet? Don't let them in at the gateway. This really isn't anything new. - -- Eric - -- Eric "Sparks" Christensen Fedora Project spa...@fedoraproject.org - spa...@redhat.com 097C 82C3 52DF C64A 50C2 E3A3 8076 ABDE 024B B3D1 - -- -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.14 (GNU/Linux) iQGcBAEBCgAGBQJSR4F7AAoJEB/kgVGp2CYvSX0L/RytQ5JrEPJXBD4t9YF63y+k QnFlaZ2dJ0l4ViVqoKpYj2Am9qK/F91ai9umGFYESzL8ipFL3M4fjBVjZJNZWojg AXrBkpZPPlWybzj7V1gaDXEZf4or1bergh3n80v+j5Iiu5arp+SUvXRwnuBSnTfl Rfb5Ej8df7LXD+9VaroG+E/cJGICWYLyc0NPIc/Q1wMc15D7XViE+G/TL5VHr5JK 9Rv640phgknSNp6Rx5E4nOBVkhON+VpmMytme+23sZla6WXpjK1u8Mg8iH2XuCti RHg5zB/PFwQaaxABY+/1WrZqd2Faox3VmCH+Zm19PsmLNdZh9otU+5JtiI1z4jhz JhI4NcqRYl0yqUC89k6vgcw42dGCfWSoAjjKPm9IpsnyXI+cFu5XTUWtIKyK3raZ FOnfUbNA1wYGwcPcPlcVOsXSU1z8NXd97diAjkhFpcsxM+ImPJrFeb3/RM1DioKV fIUls9VmrFzUAqUaDe7VZFveeWVT8D43C0nObLvFDg== =HQhA -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: [HEADSUP] Atlas changed libraries
Susi Lehtola wrote: > Again, you should file a bug to the FPC about this. Is this really the FPC's responsibility? I'd expect this to be the maintainer's, and for escalation FESCO's. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [HEADSUP] Atlas changed libraries
Susi Lehtola wrote: > If you link to -lblas, you're shooting yourself in the leg in the first > place, since that's the reference implementation on current Fedoras. In fact, I noticed that, and that's a serious packaging bug. If a package links -lblas -llapack, if ATLAS is installed, it'll get reference BLAS and ATLAS LAPACK! If it links -llapack -lblas, it'll probably get the ATLAS functions throughout, because then libatlas is resolved first. That's very unexpected and broken behavior. The ATLAS package MUST also override libblas.so.3. This is a packaging bug and must be fixed ASAP in an update to all Fedora releases. (In fact, I'd argue libatlas.so.3 should just be RENAMED to libblas.so.3, but that is obviously not so great an idea in an update, there needs to be a symlink one way or the other for compatibility reasons.) Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
dbh and/or DBH
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi all. Are the dbh package (http://pkgs.fedoraproject.org/cgit/dbh.git/) and the DBH from http://sourceforge.net/projects/dbh/files/dbh/5.0.7/ same software ? If yes, why the first is released as 1.0.24 and not as 5.0.7 ? Thanks. - -- - 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/ iQIcBAEBAgAGBQJSRyzWAAoJED2vIvfUANbEjrEP/09qVg1TbC3+jYStX8yrUH4P x/OxmSl7hYY0rZg+21tcYtIBkWcoYFR1+u5FJlzteaAGUCQ5Rd9jPiDKjQCnFlmu yT0Ypr0/wK5FPa49QkM+OJpwiwG3TvGknB6U1R4wTAZqQuDvyhfGa3ZwHSZafgGc go4Pm3do8fKHyLap41+muXBRchCPubw57626PlfWZsI3YQexTdpi3H5gF921RJbR vA0DappHJRBPmBqL06lO5oBOoWBbtiYdGnH1Hj5wAYZYMD+FeWpIjMiTEmH24ZWM a63PZOEHzHpEQZ9L0Ak5pCqpdxjYpRjN/VPKJwgPqAPMoL32kriNYKbc5iEDLclM 6Tzsw2GGHbrh8gvLc4EQ7cNLQjxwyWNsceIjvjLjedrKZ0T4x6nVrLEvEknEP2XO U8KH1DGZfNherbXCVl00eFzpf5AtVcUs+To4SknC6kAliylbmAkbpqZROwL7gPcj UP0tUay7a7xBN0xzl7UX8WuBDM+Kc1NcHLrEuB0tOBXuZnxxgCftTyCl14AJkbCR xEV375H4vW/1cAVb9faQwMOHgy064Afg7tJFQIYFQ4/QT791OmHPLGHqOyHWhTOL KBt07741Zh1Tn1JvCecaFJfts9gGEFYVoPiU1sympffZt7EO2+2fgmrOjMGrG/yP qDJFaywMjiDoCt1PnT7U =5Qnj -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: [HEADSUP] Atlas changed libraries
On Sat, 28 Sep 2013 13:01:33 +0200 Kevin Kofler wrote: > Orion Poplawski wrote: > > Upstream, upstream, upstream It's not like Fedora decided to change > > these things. > > We should indeed bring this to ATLAS upstream, opening a similar bug report > there as for OpenBLAS. However, I think we should not wait for upstream to > fix this horribly broken setup. Debian has patches for ATLAS 3.10.1 to fix > it which we would just need to apply. Again, you should file a bug to the FPC about this. -- Susi Lehtola Fedora Project Contributor jussileht...@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: [HEADSUP] Atlas changed libraries
On Sat, 28 Sep 2013 12:59:13 +0200 Kevin Kofler wrote: > I wrote: > > The existing ATLAS setup (before the change) just worked! > > Actually, I just noticed the ATLAS packages we ship in F18 are also broken: > libblas.so.3 is missing, so if something links only -lblas, or links -lblas > before -llapack etc., it will get the unoptimized reference BLAS functions! If you link to -lblas, you're shooting yourself in the leg in the first place, since that's the reference implementation on current Fedoras. If you want the ATLAS version of BLAS, you need to link -lf77blas -latlas. -- Susi Lehtola Fedora Project Contributor jussileht...@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
F-20 Branched report: 20130928 changes
Compose started at Sat Sep 28 09:15:02 UTC 2013 Broken deps for armhfp -- [blueman] blueman-1.23-7.fc20.armv7hl requires obex-data-server >= 0:0.4.3 blueman-1.23-7.fc20.armv7hl requires gvfs-obexftp [bwm-ng] bwm-ng-0.6-11.1.fc20.armv7hl requires libstatgrab.so.9 [cinnamon-translations] cinnamon-translations-1.9.2-0.4.git6091a38.fc20.noarch requires cinnamon [cloud-init] cloud-init-0.7.2-4.fc20.noarch requires dmidecode [cobbler] cobbler-2.4.0-2.fc20.noarch requires syslinux [evolution-rss] 1:evolution-rss-0.3.93-4.fc20.armv7hl requires libedataserver-1.2.so.17 1:evolution-rss-0.3.93-4.fc20.armv7hl requires libedata-book-1.2.so.19 1:evolution-rss-0.3.93-4.fc20.armv7hl requires libebackend-1.2.so.6 1:evolution-rss-0.3.93-4.fc20.armv7hl requires libcamel-1.2.so.44 [fawkes] fawkes-doc-0.5.0-9.fc20.noarch requires fawkes = 0:0.5.0-9.fc20 [fts] fts-server-3.1.1-1.fc20.armv7hl requires libactivemq-cpp.so.14 [glusterfs] glusterfs-ufo-3.4.0-8.fc20.noarch requires openstack-swift-proxy = 0:1.8.0 glusterfs-ufo-3.4.0-8.fc20.noarch requires openstack-swift-object = 0:1.8.0 glusterfs-ufo-3.4.0-8.fc20.noarch requires openstack-swift-container = 0:1.8.0 glusterfs-ufo-3.4.0-8.fc20.noarch requires openstack-swift-account = 0:1.8.0 glusterfs-ufo-3.4.0-8.fc20.noarch requires openstack-swift = 0:1.8.0 [gradle] gradle-1.0-18.fc20.noarch requires plexus-container-default [gtkd] gtkd-geany-tags-2.0.0-29.20120815git9ae9181.fc18.noarch requires gtkd = 0:2.0.0-29.20120815git9ae9181.fc18 [kawa] 1:kawa-1.11-5.fc19.armv7hl requires servlet25 [koji] koji-vm-1.8.0-2.fc20.noarch requires python-virtinst [kyua-cli] kyua-cli-0.5-3.fc19.armv7hl requires liblutok.so.0 kyua-cli-tests-0.5-3.fc19.armv7hl requires liblutok.so.0 [monotone] monotone-1.0-11.fc19.armv7hl requires libbotan-1.8.2.so perl-Monotone-1.0-11.fc19.armv7hl requires perl(:MODULE_COMPAT_5.16.2) [msp430-libc] msp430-libc-20120224-2.fc19.noarch requires msp430-gcc >= 0:4.6.3 [nifti2dicom] nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtksys.so.5.10 nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtkWidgets.so.5.10 nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtkVolumeRendering.so.5.10 nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtkViews.so.5.10 nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtkTextAnalysis.so.5.10 nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtkRendering.so.5.10 nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtkParallel.so.5.10 nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtkInfovis.so.5.10 nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtkImaging.so.5.10 nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtkIO.so.5.10 nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtkHybrid.so.5.10 nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtkGraphics.so.5.10 nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtkGeovis.so.5.10 nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtkGenericFiltering.so.5.10 nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtkFiltering.so.5.10 nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtkCommon.so.5.10 nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtkCharts.so.5.10 nifti2dicom-0.4.6-3.fc20.armv7hl requires libQVTK.so.5.10 [nocpulse-common] nocpulse-common-2.2.7-2.fc20.noarch requires perl(RHN::DBI) [openbox] gdm-control-3.5.2-2.fc20.armv7hl requires gnome-panel gnome-panel-control-3.5.2-2.fc20.armv7hl requires gnome-panel [openpts] openpts-0.2.6-7.fc20.armv7hl requires tboot [ovirt-engine] ovirt-engine-notification-service-3.1.0-1.fc19.noarch requires classpathx-mail [oyranos] oyranos-libs-0.4.0-7.fc19.armv7hl requires libraw.so.5 [perl-Language-Expr] perl-Language-Expr-0.19-4.fc19.noarch requires perl(:MODULE_COMPAT_5.16.2) [perl-MIME-Lite-HTML] perl-MIME-Lite-HTML-1.24-4.fc18.noarch requires perl(:MODULE_COMPAT_5.16.0) [perl-MooseX-TrackDirty-Attributes] perl-MooseX-TrackDirty-Attributes-2.002-2.fc19.noarch requires perl(:MODULE_COMPAT_5.16.2) [perl-Padre] perl-Padre-0.90-6.fc18.noarch requires perl(:MODULE_COMPAT_5.16.0) [player] player-3.0.2-32.fc20.armv7hl requires libstatgrab.so.9 [pure] pure-doc-0.57-4.fc20.noarch requires pure = 0:0.57-4.fc20 [python-tag] python-tag-2013.1-1.fc20.armv7hl requires libboost_python.so.1.53.0 [rootplot] rootplot-2.2.1-7.fc19.noarch requires root-python [rubygem-audited-activerecord] rubygem-audited-activerecord-3.0.0-3.fc19.noarch requires rubygem(activerecord) < 0:4 [scala] scala-2.9.2-2.fc19.noarch requires osgi(org.scala-ide.scala.library) scala-2.9.2-2.fc19.noarch requires /usr/share/java/ja
Re: About F19 Firewall
Eric H. Christensen wrote: >What are you trying to protect yourself from, exactly? Me? Other than address translation (a necessary evil) I use packet filters mostly to restrain crazy programs that open listening sockets for unknown reasons even though I don't use them for any kind of communication. There was for example some kind of Gnome daemon that popped up and started listening on an RTSP port just because I was playing music from the local disk through the local loudspeakers. Such behaviour is equally crazy on all networks, so I don't need firewall zones for that. Better ask those who think they need "home" and "work" zones what they're trying to achieve. >> This difference may be temporary though. Sooner or later ISPs will be >> forced to start providing IPv6 to customers, and then NAT will no >> longer function as a firewall. > >NAT was never really supposed to be a security feature. That's not its primary purpose, no, but not having a public IP address is in practice much like being behind a really zealous firewall that only allows outgoing connections. People rely on that when they use naïve protocols at home, for example unencrypted or passwordless file and printer sharing protocols. >IPv6 really isn't the problem. I agree. >> link-layer encryption like WPA2 won't protect anything anymore > >What do you think WPA2 protects against? It has never protected >against anything but decoding of intercepted packets across the >wireless link. As far as I know it's also supposed to prevent active attacks, not just passive eavesdropping. The underlying assumption is that your local wired network is protected by a firewall plus physical walls and locked doors, and that you have something insecure on your network that needs that protection. Then when you add a wireless link you have to prevent others from connecting to it and attacking your insecure stuff. That's what WPA2 is for. But if your firewall is just a side effect of your NAT, and IPv6 makes NAT obsolete, then your insecure stuff is no longer protected. >> ...and then >> protocols designed for an isolated friendly network will be equally >> insecure on both wired and wireless networks. > >Then you probably shouldn't be using protocols designed for an >isolated friendly network. If you do then you probably deserve what >happens to you as there is rarely such a thing as an "isolated >friendly network". And I don't use those protocols, but other people apparently do. Why else would there be a need for WPA2 or firewall zones? -- Björn Persson Sent from my computer. signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: LVM thinp expectations in anaconda 20
On 27.09.2013 20:59, Alasdair G Kergon wrote: On Fri, Sep 27, 2013 at 11:55:43AM -0600, Chris Murphy wrote: I still can't choose a Desired Capacity that's larger than free space in the VG. Ergo, I can't create a virtual size LV. Is this expected? At this stage, yes. It might change in future, but I think it was felt to be both too much code to change and too much change for users to take on board if it was all changed at once. Wouldn't it make sense to use the thinp code by default even without providing the thin provisioning part in Anaconda? This would at least give you the much improved snapshot support. Regards, 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
Re: About F19 Firewall
Will Woods wrote: > So if you actually wanted to write another yum replacement in C you > could probably start with zif, port it to use libsolv and libcomps, fix > up the CLI, and have yourself a functional prototype. There's actually some stuff in PackageKit: https://gitorious.org/packagekit/packagekit/source/4b597726bb0eb5e4c8bf318020fd9be44862b982:backends/hawkey but unfortunately not as a separate library anymore. Still, wouldn't pkcon be an option for the default CLI tool? After all, PackageKit is what we default to in the UI. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [HEADSUP] Atlas changed libraries
Orion Poplawski wrote: > Upstream, upstream, upstream It's not like Fedora decided to change > these things. We should indeed bring this to ATLAS upstream, opening a similar bug report there as for OpenBLAS. However, I think we should not wait for upstream to fix this horribly broken setup. Debian has patches for ATLAS 3.10.1 to fix it which we would just need to apply. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [HEADSUP] Atlas changed libraries
I wrote:
> The existing ATLAS setup (before the change) just worked!
Actually, I just noticed the ATLAS packages we ship in F18 are also broken:
libblas.so.3 is missing, so if something links only -lblas, or links -lblas
before -llapack etc., it will get the unoptimized reference BLAS functions!
The packaging needs to be fixed to symlink %{_libdir}/atlas*/libblas.so.3 →
libatlas.so.3.
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
