Re: flood: systemd-tmpfiles-clean.timer: time change
On 03/23/2013 01:53 PM, Reindl Harald wrote: https://bugzilla.redhat.com/show_bug.cgi?id=925916 why is systemd flooding the log at boot on VMware guests as you can see at bottom of my message I have replied in the BZ. I see no reason to treat this bug specially by discussing it on this list. while the PrivateTmp folders under /tmp are never get removed and so what is it supposed to clean at all? This has been reported in Bugzilla before. It should be fixed in the next upstream release (v199) by a patch from Michal Sekletar. Michal -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Is there a reason we do not turn on the file system hardlink/symlink protection in Rawhide?
Reading from the spec: > The solution is to permit symlinks to only be followed when outside a sticky > world-writable directory, or when the uid of the symlink and follower match, > or when the directory owner matches the symlink's owner. It was a bit unclear to me the first time I read it: I thought it was "and", not "or". So this is not as restrictive as I thought, and I'll withdraw my conerrn about this breaking linking /sbin/* or /us/sbin/* programs to $HOME//bin/. On Sun, Mar 24, 2013 at 9:19 AM, Reindl Harald wrote: > > > Am 24.03.2013 04:08, schrieb Kevin Kofler: >> Miloslav Trmač wrote: >>> BTW determining this accurately should be fairly doable[1]. Just look >>> for symlink() and link() calls (and recursively through wrapper APIs / >>> language bindings). These syscalls are fairly rare. >> >> That checks for PROGRAMS which run into this. It catches neither admin's >> custom scripts nor ln commands run directly by the users. Who knows on how >> many machines manually created symlinks point to inodes owned by different >> users? > > maybe you guys should read what the protection does > how many directories except /tmp are world-writeable and have STICKY bit? > > fs.protected_symlink > symlinks to only be followed when outside a sticky world-writable directory > > fs.protected_hardlinks > blocks hardlinks to other people's WORLD-READABLE files if you can't write to > them > > > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: New cfitsio 3.330 in Rawhide and F19 (take 2)
On Mon, 25 Mar 2013 01:44:49 +0100, Kevin Kofler wrote:
> Michael Schwendt wrote:
> > "Standard" versioning is not beneficial here at all. As explained before,
> > here the full version is part of the SONAME. Not just the major version.
> > libcfitsio.so.3.330 would be incompatible with libcfitsio.so.3.340 as
> > mentioned in a later post by Sergio (on 2013-03-22) already. There is
> > no common libcfitsio.so.3 that would be downward compatible.
>
> But there's no rule that says that the soname has to be libcfitsio.so.3
> (well, there is if the package builds using libtool, but e.g. CMake allows
> any arbitrary soname, and it also correctly handles the case where the
> soname is the same as the fully-versioned name). In cfitsio's case, the
> makefile commands writing the library are handwritten (i.e. don't use
> libtool) and thus also allow an arbitrary soname; in fact, the soname WAS
> libcfitsio.so.3.330 before you incorrectly told him to change it
Why is that incorrect?
> (based on
> the wrong assumption that he would be setting the soname to just
> libcfitsio.so.3, which would of course be wrong).
Huh? Who has made that assumption? The previous soname was libcfitsio.so.0,
which has been a bad choice for an API/ABI that changes so frequently.
> Just set the soname and the fully-versioned name both to
> "libcfitsio.so.%{version}".
That is misleading. IMHO.
> >> The version goes after .so, not before it, unless you want to have it
> >> also in the symlink, which you explicitly DON'T want here.
> >
> > Why not? It would even have been okay to name the run-time lib
> > libcfitsio-3.330.so with the implicit opportunity to use the same file
> > as the build-time lib. That would even make it possible to ship multiple
> > releases of cfitsio, since with a non-versioning build-time lib, multiple
> > -devel packages would conflict in their .so symlink (if that one is used).
>
> But then ALL packages using cfitsio have to be patched to use the versioned
> name. It just doesn't make sense.
That isn't done, however, so currently no patching is necessary.
> >> I know that going back and forth sucks (as everything will have to be
> >> rebuilt AGAIN), but I think you should really should change this back
> >> (and you should never have changed it from .so.3.330 to -3.330.so.0 in
> >> the first place).
> >
> > Either naming version would require rebuilds of dependencies for version
> > changes. So, why bother?
>
> Because libcfitsio.so → libcfitsio.so.3.330 is just the cleaner scheme
> compared to libcfitsio.so → libcfitsio-3.330.so.0. Your scheme has 2
> versions, one of which is always 0, and the devel symlink does not follow
> the pattern of pointing from foo.so to foo.so.* with the same name foo.
"Cleaner"? That's all? Then this is a superfluous discussion. It doesn't
make sense to go in circles. What you consider cleaner is just a version
that pretends that a clean versioning scheme is implemented. The added .0
does no harm. It would make it possible to change the ABI without bumping
the library version.
--
Fedora release 19 (Schrödinger’s Cat) - Linux 3.9.0-0.rc3.git1.4.fc19.x86_64
loadavg: 0.08 0.08 0.07
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Orphaned meanwhile package
Hi All, I've orphaned the meanwhile package. I no longer have a need nor the access to deal with Lotus Sametime and the upstream is pretty stagnant. The only bug I'm aware of is the new one opened to add AArch64 support, which is something you could do but I have no idea why anyone would want to connect to Sametime willingly on any architecture. josh -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
F-19 Branched report: 20130325 changes
Compose started at Mon Mar 25 09:15:07 UTC 2013 Broken deps for x86_64 -- [aeolus-conductor] aeolus-conductor-0.10.6-2.fc19.noarch requires ruby(abi) = 0:1.9.1 [aeolus-configserver] aeolus-configserver-0.5.1-2.fc19.noarch requires ruby(abi) = 0:1.9.1 [alexandria] alexandria-0.6.9-4.fc19.noarch requires ruby(abi) >= 0:1.9.1 [amide] amide-1.0.0-4.fc19.x86_64 requires libvolpack.so.1()(64bit) [archmage] archmage-0.2.4-7.fc19.noarch requires python-chm [chm2pdf] chm2pdf-0.9.1-13.fc19.noarch requires python-chm [clementine] clementine-1.1.1-1.fc19.x86_64 requires libprotobuf.so.7()(64bit) clementine-1.1.1-1.fc19.x86_64 requires libimobiledevice.so.3()(64bit) [connman] connman-1.5-4.fc19.i686 requires libxtables.so.7 connman-1.5-4.fc19.i686 requires libgnutls.so.26(GNUTLS_1_4) connman-1.5-4.fc19.i686 requires libgnutls.so.26 connman-1.5-4.fc19.x86_64 requires libxtables.so.7()(64bit) connman-1.5-4.fc19.x86_64 requires libgnutls.so.26(GNUTLS_1_4)(64bit) connman-1.5-4.fc19.x86_64 requires libgnutls.so.26()(64bit) [deltacloud-core] deltacloud-core-1.0.5-2.fc19.noarch requires ruby(abi) = 0:1.9.1 [dragonegg] dragonegg-3.1-19.fc19.x86_64 requires gcc = 0:4.7.2-9.fc19 [enblend] enblend-4.1.1-1.fc19.x86_64 requires libIlmImf.so.6()(64bit) [epiphany-extensions] epiphany-extensions-3.6.0-1.fc19.x86_64 requires epiphany(abi) = 0:3.6 [eruby] eruby-1.0.5-19.fc18.x86_64 requires libruby.so.1.9()(64bit) eruby-libs-1.0.5-19.fc18.i686 requires ruby(abi) >= 0:1.9.0 eruby-libs-1.0.5-19.fc18.i686 requires libruby.so.1.9 eruby-libs-1.0.5-19.fc18.x86_64 requires ruby(abi) >= 0:1.9.0 eruby-libs-1.0.5-19.fc18.x86_64 requires libruby.so.1.9()(64bit) [esorex] esorex-3.9.0-4.fc19.x86_64 requires libcfitsio.so.0()(64bit) [fawkes] fawkes-guis-0.5.0-5.fc19.i686 requires libgraph.so.5 fawkes-guis-0.5.0-5.fc19.x86_64 requires libgraph.so.5()(64bit) fawkes-plugin-clips-0.5.0-5.fc19.i686 requires libclipsmm.so.2 fawkes-plugin-clips-0.5.0-5.fc19.x86_64 requires libclipsmm.so.2()(64bit) fawkes-plugin-player-0.5.0-5.fc19.x86_64 requires libgeos-3.3.6.so()(64bit) fawkes-plugin-player-0.5.0-5.fc19.x86_64 requires libboost_thread-mt.so.1.50.0()(64bit) fawkes-plugin-player-0.5.0-5.fc19.x86_64 requires libboost_system-mt.so.1.50.0()(64bit) fawkes-plugin-player-0.5.0-5.fc19.x86_64 requires libboost_signals-mt.so.1.50.0()(64bit) fawkes-plugin-tabletop-objects-0.5.0-5.fc19.x86_64 requires libboost_thread-mt.so.1.50.0()(64bit) fawkes-plugin-tabletop-objects-0.5.0-5.fc19.x86_64 requires libboost_system-mt.so.1.50.0()(64bit) [flowcanvas] flowcanvas-0.7.1-8.fc18.i686 requires libgraph.so.5 flowcanvas-0.7.1-8.fc18.x86_64 requires libgraph.so.5()(64bit) [freeipa] freeipa-server-strict-3.1.2-3.fc19.x86_64 requires krb5-server = 0:1.11 freeipa-server-strict-3.1.2-3.fc19.x86_64 requires 389-ds-base = 0:1.3.0.3 [gcc-python-plugin] gcc-python2-debug-plugin-0.11-1.fc19.x86_64 requires gcc = 0:4.7.2-8.fc19 gcc-python2-plugin-0.11-1.fc19.x86_64 requires gcc = 0:4.7.2-8.fc19 gcc-python3-debug-plugin-0.11-1.fc19.x86_64 requires gcc = 0:4.7.2-8.fc19 gcc-python3-plugin-0.11-1.fc19.x86_64 requires gcc = 0:4.7.2-8.fc19 [gdal] gdal-1.9.2-2.fc19.x86_64 requires libcfitsio.so.0()(64bit) gdal-java-1.9.2-2.fc19.i686 requires libcfitsio.so.0 gdal-java-1.9.2-2.fc19.x86_64 requires libcfitsio.so.0()(64bit) gdal-libs-1.9.2-2.fc19.i686 requires libcfitsio.so.0 gdal-libs-1.9.2-2.fc19.x86_64 requires libcfitsio.so.0()(64bit) gdal-perl-1.9.2-2.fc19.x86_64 requires libcfitsio.so.0()(64bit) gdal-ruby-1.9.2-2.fc19.x86_64 requires libcfitsio.so.0()(64bit) [gdcm] gdcm-2.0.18-6.fc18.i686 requires libpoppler.so.26 gdcm-2.0.18-6.fc18.x86_64 requires libpoppler.so.26()(64bit) [gnome-applets] 1:gnome-applets-3.5.92-3.fc18.x86_64 requires libgweather-3.so.1()(64bit) [gnome-panel] gnome-panel-3.6.2-6.fc19.x86_64 requires libgnome-desktop-3.so.5()(64bit) gnome-panel-devel-3.6.2-6.fc19.i686 requires libgnome-desktop-3.so.5 gnome-panel-devel-3.6.2-6.fc19.x86_64 requires libgnome-desktop-3.so.5()(64bit) [gnome-pie] gnome-pie-0.5.3-3.20120826git1b93e1.fc19.x86_64 requires libbamf3.so.0()(64bit) [gnomint] gnomint-1.2.1-5.fc18.x86_64 requires libgnutls.so.26(GNUTLS_2_8)(64bit) gnomint-1.2.1-5.fc18.x86_64 requires libgnutls.so.26(GNUTLS_1_4)(64bit) gnomint-1.2.1-5.fc18.x86_64 requires libgnutls.so.26()(64bit) [gooddata-cl] gooddata-cl-1.2.56-2.fc19.noarch requires gdata-java [kawa] 1:kawa-1.11-5.fc19.x86_64 requires servlet25 [libkolab] php-kolab-0.4.
gdal-java problems
Hi! Who can check this? DEBUG util.py:264: Error: Package: gdal-java-1.9.2-2.fc19.x86_64 (build) DEBUG util.py:264: Requires: libcfitsio.so.0()(64bit) DEBUG util.py:264: Error: Package: gdal-libs-1.9.2-2.fc19.x86_64 (build) DEBUG util.py:264: Requires: libcfitsio.so.0()(64bit) -of -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: gdal-java problems
On Mon, 2013-03-25 at 13:53 +0100, Oliver Falk wrote: > Hi! > > Who can check this? > > DEBUG util.py:264: Error: Package: gdal-java-1.9.2-2.fc19.x86_64 (build) > DEBUG util.py:264: Requires: libcfitsio.so.0()(64bit) > DEBUG util.py:264: Error: Package: gdal-libs-1.9.2-2.fc19.x86_64 (build) > DEBUG util.py:264: Requires: libcfitsio.so.0()(64bit) > > -of > It needs a rebuild, but there's a bit of a back and forth with cfitsio at the moment. Therefore I didn't rebuild it yet. Volker Fröhlich -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Orphaning libmatchbox
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Since sandbox has moved over to use openbox. (Someday I dream of it using gnome-shell) I no longer need libmatchbox, and since I believe sandbox was the last app to require it, we could probably retire the package, unless anyone else needs it. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.13 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlFQUUUACgkQrlYvE4MpobPT0QCfUjX+0yZ8OwLR0VfzYAgg9Jmo CZgAoKbkw/nCWyLP93zEaMh3aTOYvzMc =KSvf -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Orphaned meanwhile package
On 2013-03-25, 12:24 GMT, Josh Boyer wrote: > I've orphaned the meanwhile package. I no longer have a need nor the > access to deal with Lotus Sametime and the upstream is pretty stagnant. > The only bug I'm aware of is the new one opened to add AArch64 support, > which is something you could do but I have no idea why anyone would > want to connect to Sametime willingly on any architecture. There are those poor sould working for a company which fallen for IBM Lotus Notes. I know couple of them. Sad people. Matěj -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Kickstart package groups (F18+)
Jos Vos (j...@xos.nl) said: > On Sun, Mar 24, 2013 at 09:32:35AM -0700, Adam Williamson wrote: > > > It's still what's listed in comps. What are you trying that doesn't > > work? > > True. I was confused by (the combination of) the "category" items > in comps.xml (they can't be used it seems, wouldn't it be a good > idea to allow them too?), the now obsoleted examples in the F18 > installation guide > http://docs.fedoraproject.org/en-US/Fedora/18/html/Installation_Guide/s1-kickstart2-packageselection.html > and what was listed > in http://fedoraproject.org/wiki/Features/ReworkPackageGroups . categories remains for use by the assorted post-install tools as items that guide the UI; they are not used in anaconda. Anaconda uses the environment groups. Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: config.guess/config.sub for aarch64 (was Re: Mass Rebuild for Fedora 19)
On 02/08/2013 09:30 AM, Brendan Conoboy wrote: On 02/08/2013 07:12 AM, Tom Lane wrote: Dennis Gilmore writes: Additionally we will be mass patching config.guess and config.sub to support aarch64 in preperation for 64 bit arm support Hm, it would be much better in the long run to pester upstreams to update to an appropriate version of these files. Are the required changes in upstream autoconf yet, and if so what version? If not, why not? Support for aarch64 landed in autoconf 2.69 which was released on March 25th and first built in Fedora on May 15th. Packages that use autoconf 2.69 are already good to go. Isn't config.sub/config.guess really a part of automake and it is that that needs updating by upstream? For instance, configure in octave 3.6.4 says it was generated by autoconf 2.69, but the config.guess/config.sub files don't have aarch64. What version of automake added aarch64? -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA, Boulder Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 http://www.nwra.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Orphaned meanwhile package
I'm one of those poor souls having to deal with Lotus Notes at work. Well, actually my soul is kidnapped in Hell and I'm forced to work with the damn tool for repentance. Words are not enough to describe the unbearable agony that the super fat Lotus Notes native client and the funtastic iNotes web interface bring to my life. I started thinking we do this for charity towards the Notes sysadmins. Having said that, I need Sametime, and meanwhile has a few bugs open upstream in Empathy, one of which is the missing field to specify which server to connect to (!!) in the account settings. If there's nobody else who wants to step in, I would like to be the mantainer; any help from co-mantainers is much welcome. Thanks, --Simone PS: if you need any help running Lotus Notes on recent Fedora releases, feel free to write me. On 25 March 2013 20:00, Matej Cepl wrote: > On 2013-03-25, 12:24 GMT, Josh Boyer wrote: > > I've orphaned the meanwhile package. I no longer have a need nor the > > access to deal with Lotus Sametime and the upstream is pretty stagnant. > > The only bug I'm aware of is the new one opened to add AArch64 support, > > which is something you could do but I have no idea why anyone would > > want to connect to Sametime willingly on any architecture. > > There are those poor sould working for a company which fallen for IBM > Lotus Notes. I know couple of them. Sad people. > > Matěj > > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel -- You cannot discover new oceans unless you have the courage to lose sight of the shore (R. W. Emerson). -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: config.guess/config.sub for aarch64 (was Re: Mass Rebuild for Fedora 19)
On Mon, 25 Mar 2013 14:36:17 -0600, Orion Poplawski wrote: > Isn't config.sub/config.guess really a part of automake and it is that that > needs updating by upstream? For instance, configure in octave 3.6.4 says it > was generated by autoconf 2.69, but the config.guess/config.sub files don't > have aarch64. What version of automake added aarch64? What does the "timestamp" value at the beginning of the config.guess file contain? It may be that upstream needs to "force"-update the files, e.g. with "autoreconf -f" (or the similar -f commands for the various autotools). -- Fedora release 19 (Schrödinger’s Cat) - Linux 3.9.0-0.rc3.git1.4.fc19.x86_64 loadavg: 0.11 0.34 0.33 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: config.guess/config.sub for aarch64 (was Re: Mass Rebuild for Fedora 19)
On Mon, Mar 25, 2013 at 8:36 PM, Orion Poplawski wrote: > On 02/08/2013 09:30 AM, Brendan Conoboy wrote: >> >> On 02/08/2013 07:12 AM, Tom Lane wrote: >>> >>> Dennis Gilmore writes: Additionally we will be mass patching config.guess and config.sub to support aarch64 in preperation for 64 bit arm support >>> >>> >>> Hm, it would be much better in the long run to pester upstreams to >>> update to an appropriate version of these files. Are the required >>> changes in upstream autoconf yet, and if so what version? If not, >>> why not? >> >> >> Support for aarch64 landed in autoconf 2.69 which was released on March >> 25th >> and first built in Fedora on May 15th. Packages that use autoconf 2.69 >> are >> already good to go. >> > > Isn't config.sub/config.guess really a part of automake and it is that that > needs updating by upstream? For instance, configure in octave 3.6.4 says it > was generated by autoconf 2.69, but the config.guess/config.sub files don't > have aarch64. What version of automake added aarch64? 2.69 added it, I've seen that on a couple of packages but adding -vif on the end fixes it. Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: config.guess/config.sub for aarch64 (was Re: Mass Rebuild for Fedora 19)
On Mon, 2013-03-25 at 15:03 -0600, Orion Poplawski wrote: > automake -f -a -c > > to force it to copy in all needed files again. Just run: autoreconf -v -f -i always. Better, ensure the upstream has an autogen.sh containing whatever they need to do to build from actual revision control (as opposed to tarballs). Typically, an autogen.sh which contains: #!/bin/sh exec autoreconf -v -f -i is sufficient, unless gtk-doc or intltool are involved. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: config.guess/config.sub for aarch64 (was Re: Mass Rebuild for Fedora 19)
On 03/25/2013 09:36 PM, Orion Poplawski wrote: On 02/08/2013 09:30 AM, Brendan Conoboy wrote: On 02/08/2013 07:12 AM, Tom Lane wrote: Dennis Gilmore writes: Additionally we will be mass patching config.guess and config.sub to support aarch64 in preperation for 64 bit arm support Hm, it would be much better in the long run to pester upstreams to update to an appropriate version of these files. Are the required changes in upstream autoconf yet, and if so what version? If not, why not? Support for aarch64 landed in autoconf 2.69 which was released on March 25th and first built in Fedora on May 15th. Packages that use autoconf 2.69 are already good to go. Isn't config.sub/config.guess really a part of automake and it is that that needs updating by upstream? config.sub/config.guess are part of the gnu "config" project: http://savannah.gnu.org/git/?group=config automake releases usually incorporate the version which is current at the time of a new automake release. For instance, configure in octave 3.6.4 says it was generated by autoconf 2.69, but the config.guess/config.sub files don't have aarch64. Autoconf-2.69 - This is entirely unrelated config.sub/guess. What version of automake added aarch64? I don't know when it was added, but automake-1.13 has it. My recommendation: Instead of mucking around with automake/autoreconf-1.13+ and its incompatiblities, get the current version of config.guess/config.sub from the config project and add them as a patch to your package. Ralf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: config.guess/config.sub for aarch64 (was Re: Mass Rebuild for Fedora 19)
On 03/25/2013 02:50 PM, Michael Schwendt wrote: On Mon, 25 Mar 2013 14:36:17 -0600, Orion Poplawski wrote: Isn't config.sub/config.guess really a part of automake and it is that that needs updating by upstream? For instance, configure in octave 3.6.4 says it was generated by autoconf 2.69, but the config.guess/config.sub files don't have aarch64. What version of automake added aarch64? What does the "timestamp" value at the beginning of the config.guess file contain? It may be that upstream needs to "force"-update the files, e.g. with "autoreconf -f" (or the similar -f commands for the various autotools). Looks like you need to run: automake -f -a -c to force it to copy in all needed files again. But again, these files appear to come from automake not autoconf, which makes the bug reports filed inaccurate. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA, Boulder Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 http://www.nwra.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: config.guess/config.sub for aarch64 (was Re: Mass Rebuild for Fedora 19)
On 03/25/2013 10:04 PM, Peter Robinson wrote: 2.69 added it, No - autoconf does not distribute config.guess/config.sub to packages. It's automake. Ralf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Kickstart package groups (F18+)
On Mon, Mar 25, 2013 at 03:05:38PM -0400, Bill Nottingham wrote: > categories remains for use by the assorted post-install tools as > items that guide the UI; they are not used in anaconda. Anaconda > uses the environment groups. But it does not seem to be possible to specify an environment as group in kickstart's %packages, right? -- --Jos Vos --X/OS Experts in Open Systems BV | Phone: +31 20 6938364 --Amsterdam, The Netherlands| Fax: +31 20 6948204 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: config.guess/config.sub for aarch64 (was Re: Mass Rebuild for Fedora 19)
On 03/25/2013 02:16 PM, Ralf Corsepius wrote: On 03/25/2013 10:04 PM, Peter Robinson wrote: 2.69 added it, No - autoconf does not distribute config.guess/config.sub to packages. It's automake. Autoconf 2.69 is the first version of autoconf that included aarch64 in its config.guess and config.sub, but you are right: It is automake that provides these files. Specifically, automake 1.11.4 is the first version of automake to provide a config.guess and config.sub pair that includes aarch64 recognition. This is a mistake on my part- I was under the impression autoconf provided them. The bug report's suggestion of running autoreconf will still have the desired effect, but the 'autoconf' suggestion was off. Sorry about that. -- Brendan Conoboy / Red Hat, Inc. / b...@redhat.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: config.guess/config.sub for aarch64 (was Re: Mass Rebuild for Fedora 19)
On 03/25/2013 01:36 PM, Orion Poplawski wrote: What version of automake added aarch64? Autoamke 1.11.4, evidently. -- Brendan Conoboy / Red Hat, Inc. / b...@redhat.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: New cfitsio 3.330 in Rawhide and F19 (take 2)
I have written cfitsio upstream, requesting that they include a soname in
the library.
Regarding our current discussion, the only requirement is that the soname
is unique
for each release. This comes for the infamous function call that checks the
library version at runtime. In this sense,
libcfitsio-3.340.so.0 and libcfitsio.so.3.340 are equally valid.
In /usr/lib there are lots of libraries with different versioning schemes.
Some include the package version, some not. We have even a library that
includes fc18 in the soname,
$ objdump -p /usr/lib64/libopcodes-2.23.51.0.1-6.fc18.so|grep SONAME
SONAME libopcodes-2.23.51.0.1-6.fc18.so
I feel reluctant to rebuild the package and all dependant packages now just
to remove the .0, that is harmless. I will remove it in the next release.
Hopefully the soname will be provided by upstream then.
Regards
2013/3/25 Michael Schwendt
> On Mon, 25 Mar 2013 01:44:49 +0100, Kevin Kofler wrote:
>
> > Michael Schwendt wrote:
> > > "Standard" versioning is not beneficial here at all. As explained
> before,
> > > here the full version is part of the SONAME. Not just the major
> version.
> > > libcfitsio.so.3.330 would be incompatible with libcfitsio.so.3.340 as
> > > mentioned in a later post by Sergio (on 2013-03-22) already. There is
> > > no common libcfitsio.so.3 that would be downward compatible.
> >
> > But there's no rule that says that the soname has to be libcfitsio.so.3
> > (well, there is if the package builds using libtool, but e.g. CMake
> allows
> > any arbitrary soname, and it also correctly handles the case where the
> > soname is the same as the fully-versioned name). In cfitsio's case, the
> > makefile commands writing the library are handwritten (i.e. don't use
> > libtool) and thus also allow an arbitrary soname; in fact, the soname WAS
> > libcfitsio.so.3.330 before you incorrectly told him to change it
>
> Why is that incorrect?
>
> > (based on
> > the wrong assumption that he would be setting the soname to just
> > libcfitsio.so.3, which would of course be wrong).
>
> Huh? Who has made that assumption? The previous soname was libcfitsio.so.0,
> which has been a bad choice for an API/ABI that changes so frequently.
>
> > Just set the soname and the fully-versioned name both to
> > "libcfitsio.so.%{version}".
>
> That is misleading. IMHO.
>
> > >> The version goes after .so, not before it, unless you want to have it
> > >> also in the symlink, which you explicitly DON'T want here.
> > >
> > > Why not? It would even have been okay to name the run-time lib
> > > libcfitsio-3.330.so with the implicit opportunity to use the same file
> > > as the build-time lib. That would even make it possible to ship
> multiple
> > > releases of cfitsio, since with a non-versioning build-time lib,
> multiple
> > > -devel packages would conflict in their .so symlink (if that one is
> used).
> >
> > But then ALL packages using cfitsio have to be patched to use the
> versioned
> > name. It just doesn't make sense.
>
> That isn't done, however, so currently no patching is necessary.
>
> > >> I know that going back and forth sucks (as everything will have to be
> > >> rebuilt AGAIN), but I think you should really should change this back
> > >> (and you should never have changed it from .so.3.330 to -3.330.so.0 in
> > >> the first place).
> > >
> > > Either naming version would require rebuilds of dependencies for
> version
> > > changes. So, why bother?
> >
> > Because libcfitsio.so → libcfitsio.so.3.330 is just the cleaner scheme
> > compared to libcfitsio.so → libcfitsio-3.330.so.0. Your scheme has 2
> > versions, one of which is always 0, and the devel symlink does not follow
> > the pattern of pointing from foo.so to foo.so.* with the same name foo.
>
> "Cleaner"? That's all? Then this is a superfluous discussion. It doesn't
> make sense to go in circles. What you consider cleaner is just a version
> that pretends that a clean versioning scheme is implemented. The added .0
> does no harm. It would make it possible to change the ABI without bumping
> the library version.
>
> --
> Fedora release 19 (Schrödinger’s Cat) - Linux
> 3.9.0-0.rc3.git1.4.fc19.x86_64
> loadavg: 0.08 0.08 0.07
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
>
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
[Test-Announce] Fedora 19 Alpha Test Compose 2 (TC2) Available Now!
*IMPORTANT*: All DVDs and Lives are oversized, so will not fit on the standard media. As per the Fedora 19 schedule [1], Fedora 19 Alpha Test Compose 2 (TC2) is now available for testing. Content information, including changes, can be found at https://fedorahosted.org/rel-eng/ticket/5545#comment:3 . 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 19 Alpha test composes (TC) and release candidates (RC) https://fedorahosted.org/rel-eng/ticket/5545 Current Blocker and NTH bugs: http://qa.fedoraproject.org/blockerbugs/current [1] http://fedorapeople.org/groups/schedule/f-19/f-19-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_19_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
