Re: Anyone interested in abi-compatibility-checker?
- Original Message - > From: "Richard Shaw" > To: "Development discussions related to Fedora" > > Sent: Friday, 18 November, 2011 5:41:19 AM > Subject: Re: Anyone interested in abi-compatibility-checker? > > Just an FYI to anyone who's interested. The builds are on their way > to > updates-testing. > > https://bugzilla.redhat.com/show_bug.cgi?id=753900 > Thanks, I'll find it useful. I maintain a c lib and was meaning to add something like this to my release cycle. -Angus > Richard > -- > 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: push direct to stable?
On Thu, 2011-11-17 at 20:26 -0500, Neal Becker wrote: > Is it possible to push this update direct to stable to close this bug? > > https://bugzilla.redhat.com/show_bug.cgi?id=754741 > > https://admin.fedoraproject.org/updates/kdiff3-0.9.96-5.fc16 It's not critical path, so you only need a single karma point from anyone with a FAS account to submit it to stable. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
push direct to stable?
Is it possible to push this update direct to stable to close this bug? https://bugzilla.redhat.com/show_bug.cgi?id=754741 https://admin.fedoraproject.org/updates/kdiff3-0.9.96-5.fc16 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Systemd unit file executed as non-root user, WAS: Systemd unit file: Can/Should ExecStart and ExecStop run a script?
On 17/11/11 22:09, Richard Shaw wrote: > On Thu, Nov 17, 2011 at 3:56 PM, Richard Shaw wrote: >> On Thu, Nov 17, 2011 at 3:41 PM, Jeffrey Ollie wrote: >>> On Thu, Nov 17, 2011 at 3:34 PM, Richard Shaw wrote: Ok, reviving this conversation! I ran into the issue that user "mythtv" can not create the file "/var/run/mythbackend.pid". I see other services that have their pid file owned by their own user... >>> >>> systemd doesn't really need a PID file to manage the service, can >>> mythtv be told not to create it? If it insists on creating it see if >>> you can move it to a subdirectory of /run (like /run/mythtv) that is >>> owned by mythtv. >> >> Well PIDFile is recommended when using type forking. One option would >> be to drop the "--daemon" option and move to type "simple". > > I tried this and it appears to work. The other option is to create a file in /etc/tmpfiles.d that defines the /var/run/mythtv (or /run/mythtv) directory so that you can then write the PID file to it. Also, user "mythtv" can't write to the log file in /var/log/mythtv/ >>> >>> Change the ownership of /var/log/mythtv. > > I added "install -d -o mythtv -g mythtv /var/log/mythtv" to %post for > the backend package. Is there a better way to do this? Yes! Create it in the %install section if the spec file and then add it to the files list. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: python-fedora update for F-14 brings in additional 57 packages
On Thu, 2011-11-17 at 14:33 -0800, Toshio Kuratomi wrote: > On Thu, Nov 17, 2011 at 11:28:48PM +0100, Dominik 'Rathann' Mierzejewski > wrote: > > Hi list, > > could someone explain why an update in a branch that's supposed > > to be stable and is nearing EOL requires me to download 14MB worth > > of additional packages (57 extra dependencies) for a 360KB package? > > Doesn't this go against our update guidelines? > > > AFAICT, it does not. For the rest of the story look at the bug report: > https://bugzilla.redhat.com/show_bug.cgi?id=754538 And remember that tools like python-fedora are to an extent a special case: F14's python-fedora doesn't only have to be able to build F14 packages, we want people using F14 to be able to work on F15, F16 and Rawhide. So if we want to make adventurous changes to the package building system and tools we kind of have to backport those changes even to 'very stable' releases. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: python-fedora update for F-14 brings in additional 57 packages
On Thu, Nov 17, 2011 at 11:28:48PM +0100, Dominik 'Rathann' Mierzejewski wrote: > Hi list, > could someone explain why an update in a branch that's supposed > to be stable and is nearing EOL requires me to download 14MB worth > of additional packages (57 extra dependencies) for a 360KB package? > Doesn't this go against our update guidelines? > AFAICT, it does not. For the rest of the story look at the bug report: https://bugzilla.redhat.com/show_bug.cgi?id=754538 -Toshio pgpm9WZEjDkxp.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
python-fedora update for F-14 brings in additional 57 packages
Hi list, could someone explain why an update in a branch that's supposed to be stable and is nearing EOL requires me to download 14MB worth of additional packages (57 extra dependencies) for a 360KB package? Doesn't this go against our update guidelines? For the record, the installed version is 0.3.24-1.fc14, so it's supposedly a very minor update to 0.3.25.1. I certainly wasn't expecting a ton of extra dependencies. # yum update Loaded plugins: auto-update-debuginfo, fastestmirror, presto Loading mirror speeds from cached hostfile * fedora: ftp.icm.edu.pl * rpmfusion-free: ftp.icm.edu.pl * rpmfusion-free-updates: ftp.icm.edu.pl * rpmfusion-nonfree: ftp.icm.edu.pl * rpmfusion-nonfree-updates: ftp.icm.edu.pl * updates: ftp.uni-erlangen.de Setting up Update Process Resolving Dependencies --> Running transaction check ---> Package python-fedora.noarch 0:0.3.25.1-1.fc14.1 set to be updated --> Processing Dependency: python-mako >= 0.3.6 for package: python-fedora-0.3.25.1-1.fc14.1.noarch --> Processing Dependency: TurboGears2 for package: python-fedora-0.3.25.1-1.fc14.1.noarch --> Processing Dependency: Django for package: python-fedora-0.3.25.1-1.fc14.1.noarch --> Processing Dependency: TurboGears for package: python-fedora-0.3.25.1-1.fc14.1.noarch --> Processing Dependency: python-repoze-who-friendlyform for package: python-fedora-0.3.25.1-1.fc14.1.noarch --> Running transaction check ... Dependencies Resolved Package Arch Version Repository Size Updating: python-fedoranoarch 0.3.25.1-1.fc14.1 updates 358 k Installing for dependencies: [...] Transaction Summary Install 57 Package(s) Upgrade 1 Package(s) Total download size: 14 M Is this ok [y/N]: N Exiting on user Command Complete! Regards, Dominik -- Fedora http://fedoraproject.org/wiki/User:Rathann RPMFusion http://rpmfusion.org | MPlayer http://mplayerhq.hu "Faith manages." -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations" -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Systemd unit file executed as non-root user, WAS: Systemd unit file: Can/Should ExecStart and ExecStop run a script?
On Thu, Nov 17, 2011 at 3:56 PM, Richard Shaw wrote: > On Thu, Nov 17, 2011 at 3:41 PM, Jeffrey Ollie wrote: >> On Thu, Nov 17, 2011 at 3:34 PM, Richard Shaw wrote: >>> Ok, reviving this conversation! >>> >>> I ran into the issue that user "mythtv" can not create the file >>> "/var/run/mythbackend.pid". I see other services that have their pid >>> file owned by their own user... >> >> systemd doesn't really need a PID file to manage the service, can >> mythtv be told not to create it? If it insists on creating it see if >> you can move it to a subdirectory of /run (like /run/mythtv) that is >> owned by mythtv. > > Well PIDFile is recommended when using type forking. One option would > be to drop the "--daemon" option and move to type "simple". I tried this and it appears to work. >>> Also, user "mythtv" can't write to the log file in /var/log/mythtv/ >> >> Change the ownership of /var/log/mythtv. I added "install -d -o mythtv -g mythtv /var/log/mythtv" to %post for the backend package. Is there a better way to do this? Thanks, Richard -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Systemd unit file: Can/Should ExecStart and ExecStop run a script?
On Thu, Nov 17, 2011 at 3:41 PM, Jeffrey Ollie wrote: > On Thu, Nov 17, 2011 at 3:34 PM, Richard Shaw wrote: >> Ok, reviving this conversation! >> >> I ran into the issue that user "mythtv" can not create the file >> "/var/run/mythbackend.pid". I see other services that have their pid >> file owned by their own user... > > systemd doesn't really need a PID file to manage the service, can > mythtv be told not to create it? If it insists on creating it see if > you can move it to a subdirectory of /run (like /run/mythtv) that is > owned by mythtv. Well PIDFile is recommended when using type forking. One option would be to drop the "--daemon" option and move to type "simple". >> Also, user "mythtv" can't write to the log file in /var/log/mythtv/ > > Change the ownership of /var/log/mythtv. Yup, I can add that to the spec file so it will be handled during install... Richard -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Systemd unit file: Can/Should ExecStart and ExecStop run a script?
On Thu, Nov 17, 2011 at 3:34 PM, Richard Shaw wrote: > Ok, reviving this conversation! > > I ran into the issue that user "mythtv" can not create the file > "/var/run/mythbackend.pid". I see other services that have their pid > file owned by their own user... systemd doesn't really need a PID file to manage the service, can mythtv be told not to create it? If it insists on creating it see if you can move it to a subdirectory of /run (like /run/mythtv) that is owned by mythtv. > Also, user "mythtv" can't write to the log file in /var/log/mythtv/ Change the ownership of /var/log/mythtv. -- Jeff Ollie -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Systemd unit file: Can/Should ExecStart and ExecStop run a script?
Ok, reviving this conversation! I ran into the issue that user "mythtv" can not create the file "/var/run/mythbackend.pid". I see other services that have their pid file owned by their own user... Also, user "mythtv" can't write to the log file in /var/log/mythtv/ How do I do this with systemd? I assume I can update the ownership of /var/log/mythtv during package install, but I don't know what I can do about /var/run... Thanks, Richard -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
syslinux package spec file
Main package "syslinux" does:
Obsoletes: syslinux-devel < %{version}-%{release}
Provides: syslinux-devel
However, a syslinux-devel subpackage definition is present. A -devel
package is built. No comment explains above Obs/Prov pair.
%changelog only says:
* Thu Dec 17 2009 Peter Jones … - 3.83-2
- Split out -devel
* Tue Aug 22 2006 Jesse Keating … - 3.11-4
- Obsolete syslinux-devel.
- Couple cleanups for packaging guidelines
* Mon Jun 12 2006 Peter Jones … - 3.11-2
- Fold -devel subpackage into "syslinux"
# repoquery --archlist=src --whatrequires syslinux --disablerepo='*'
--enablerepo=fedora-source
gpxe-0:1.0.1-4.fc16.src
ltsp-0:5.1.95-3.fc16.src
# repoquery --archlist=src --whatrequires syslinux-devel --disablerepo='*'
--enablerepo=fedora-source
#
--
Fedora release 16 (Verne) - Linux 3.1.1-2.fc16.x86_64
loadavg: 0.17 0.10 0.07
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: scripts without she-bang in /usr/lib/packagename/
On Thu, 17 Nov 2011, Toshio Kuratomi wrote:
> And also note -- the use of /usr/lib (*not* %{_libdir}) vs /usr/share
> is debatable (I said "could" above rather than should). The modules that go
> into the default search path, for python, perl, and ruby, for instance, all
> end up in /usr/lib if they're written purely in the scripting language.
>
> The arguments for either side are:
>
> /usr/share => shareable between architectures. Thus a sysadmin can save on
> disk space by network mounting /usr/share and all the files it contains on
> any of the systems they manage. Most scripting language modules fit into
> this.
>
> /usr/lib => for object files, libraries, and internal binaries. The script
> modules are code being used inside of an executable. So there is a case to
> be made to have them fall under the "libraries" definition.
>
> I don't think this is something to get into a big fight with upstream about;
> leaving the files 0644 and ignoring rpmlint is valid in this case.
Thanks. I'll do that.
Paul
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rawhide report: 20111117 changes
On Thu, Nov 17, 2011 at 12:36:36PM +, Rawhide Report wrote: > 1:libguestfs-1.15.3-3.fc17.i686 requires /usr/lib/libkdb5.so.5 > 1:libguestfs-1.15.3-3.fc17.x86_64 requires /usr/lib64/libkdb5.so.5 Should be fixed now. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into Xen guests. http://et.redhat.com/~rjones/virt-p2v -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
cone : potentially orphaned package
2011-06-23 : FTBFS not responded to 2010-06-30 : -static packaging bug not responded to Plus, release 0.89 from 20-May-2011 is available whereas Fedora contains 0.84 from 2010 ( http://sourceforge.net/projects/courier/files/cone/ ). This looks like somebody with interest in Cone should sign up as co-maintainer and find out what's up with the current maintainer. http://bugz.fedoraproject.org/cone -- Fedora release 16 (Verne) - Linux 3.1.1-2.fc16.x86_64 loadavg: 0.82 1.09 0.87 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Need help with bundled lib issue for OpenColorIO
On Thu, Nov 17, 2011 at 10:31 AM, Toshio Kuratomi wrote: [SNIP] >> > Only if he's significantly modifying the bundled libs and upstream won't >> > take the changes. If you unbundle and build against the system versions, >> > and it works, that's what you need to do. Always link dynamically if at >> > all possible. >> >> Ok, so the public/private API's won't be a problem? >> > I'm not quite sure what he means by public/private API. If he's saying that > the end user doesn't see the xml and yaml libraries's APIs that seems like > it's tangential to the issue. I've had some further communication with upstream and they have agreed that the libraries in question need to be unbundled, but may in the meantime seek an exception. The reason for this is that the two libraries are mainly used for serialization and they are concerned that it may not work correctly/dependably across the different versions of the library in different distro's. This is a summary, see this link[1] for his full explanation. I think part of their immediate hesitation is that this is apparently an industrial grade app that has been used by Sony for use in movies (such as Cloudy With A chance of Meatballs) and they want to make sure it works the same on all platforms (the one big positive with bundled libs). >> He did mention they were patched, some of it for build reasons (no >> problem) but some of it was to make it work. He's going to check to >> see if those patches have made their way into upstream. >> > If upstream hasn't taken them yet, it's possible that our packages could > carry the changes. It depends on the maintainer of the library package, > whether the upstream is going to merge the changes eventually, and whether > they cause incompatibilities. Something to keep in mind. They are looking into whether their patches have made it upstream or not, so that's TBD. Thanks, Richard [1] https://github.com/imageworks/OpenColorIO/pull/183#issuecomment-2777004 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: scripts without she-bang in /usr/lib/packagename/
On Thu, Nov 17, 2011 at 01:09:47PM -0500, Paul Wouters wrote:
> On Thu, 17 Nov 2011, Toshio Kuratomi wrote:
>
> > When you talk about scripts, do you mean that the code calling these scripts
> > does the equivalent of this (note, I generated my examples by reading up on
> > ruby on the web just prior to posting... please allow for this perhaps not
> > being real ruby code :-))::
> >
> > system('/usr/lib/packagename/foo.rb')
> >
> > or this::
> >
> > require '/usr/lib/packagename/foo.rb'
>
> This is what is used.
>
> > Foo::run()
> >
> > or this::
> >
> > system('/usr/bin/ruby /usr/lib/packagename/foo.rb')
> >
> > The first example needs a shebang. The second example should be mode 0644
> > and you could place them in /usr/share/packagename/.
>
> Ahh. I thought /usr/share should not contain any executable code, including
> modules. But I cannot find a clear reference to that on
> http://fedoraproject.org/wiki/Packaging:Guidelines
>
> I'll talk to upstream about the default install location, as I think it would
> not be wise for the fedora package the hack those paths.
>
And also note -- the use of /usr/lib (*not* %{_libdir}) vs /usr/share
is debatable (I said "could" above rather than should). The modules that go
into the default search path, for python, perl, and ruby, for instance, all
end up in /usr/lib if they're written purely in the scripting language.
The arguments for either side are:
/usr/share => shareable between architectures. Thus a sysadmin can save on
disk space by network mounting /usr/share and all the files it contains on
any of the systems they manage. Most scripting language modules fit into
this.
/usr/lib => for object files, libraries, and internal binaries. The script
modules are code being used inside of an executable. So there is a case to
be made to have them fall under the "libraries" definition.
I don't think this is something to get into a big fight with upstream about;
leaving the files 0644 and ignoring rpmlint is valid in this case.
-Toshio
pgpryggNIDamx.pgp
Description: PGP signature
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Anyone interested in abi-compatibility-checker?
Just an FYI to anyone who's interested. The builds are on their way to updates-testing. https://bugzilla.redhat.com/show_bug.cgi?id=753900 Richard -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [Test-Announce] Announcing the release of Fedora 16.
On Nov 14, 2011, at 3:38 PM, Adam Williamson wrote: > > On Tue, 2011-11-08 at 17:48 +0100, Gerd Hoffmann wrote: >> Hi, >> >>> Fedora 16 is not science fiction. It is here right now: >>> http://get.fedoraproject.org >> >> Hmm, no jigdo downloads any more? > > Releng say they dropped jigdo due to overwhelming indifference (the > download numbers for the jigdo images were tiny). When releng agreed to do jigdo, the proponents of it promised better tooling in the near future to create the jigdo data. That tooling was never delivered, and the process to create jigdo data continues to be manual, arduous, error prone, and still difficult for clients to manage. While I wasn't part of the decision to drop it, I wholly support the decision. -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: New build of fedpkg (fedora-packager) coming to updates-testing / rawhide
On Nov 15, 2011, at 1:54 AM, Marek Goldmann wrote: > > I see the same issue with "clone" on F16: > > [goldmann@nightmare fedora]$ fedpkg clone appliance-tools > Could not execute clone: must be type, not classobj > [goldmann@nightmare fedora]$ rpm -q fedpkg > fedpkg-1.5-1.fc16.noarch > > Downgrading to fedpkg-1.1-1.fc16.noarch helped. Somebody reported this when they didn't have the right ssl certs in place. With the newer fedpkg installed, can you do a fedpkg clone -v appliance-tools ? -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: scripts without she-bang in /usr/lib/packagename/
On Thu, 17 Nov 2011, Toshio Kuratomi wrote:
> When you talk about scripts, do you mean that the code calling these scripts
> does the equivalent of this (note, I generated my examples by reading up on
> ruby on the web just prior to posting... please allow for this perhaps not
> being real ruby code :-))::
>
> system('/usr/lib/packagename/foo.rb')
>
> or this::
>
> require '/usr/lib/packagename/foo.rb'
This is what is used.
> Foo::run()
>
> or this::
>
> system('/usr/bin/ruby /usr/lib/packagename/foo.rb')
>
> The first example needs a shebang. The second example should be mode 0644
> and you could place them in /usr/share/packagename/.
Ahh. I thought /usr/share should not contain any executable code, including
modules. But I cannot find a clear reference to that on
http://fedoraproject.org/wiki/Packaging:Guidelines
I'll talk to upstream about the default install location, as I think it would
not be wise for the fedora package the hack those paths.
Thanks,
Paul
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: scripts without she-bang in /usr/lib/packagename/
On Thu, Nov 17, 2011 at 12:26:13PM -0500, Paul Wouters wrote:
>
> I have a package that contains ruby scripts in /usr/lib/packagename/
>
> These scripts are only called/included via other binaries.
>
> If I do not make these executable, then rpmlint complains about
> non-executable content in /usr/lib/packagename/ and suggests I
> move it to /usr/share/packagename. If I make them executable, then it
> complains about missing she-bang.
>
> upstream thinks there is no problem and says the scripts should never
> be executed on their own, so no she-bang should be there. Fedora does
> not allow executing from /usr/share.
>
> Should I just ignore rpmlint for this case?
>
When you talk about scripts, do you mean that the code calling these scripts
does the equivalent of this (note, I generated my examples by reading up on
ruby on the web just prior to posting... please allow for this perhaps not
being real ruby code :-))::
system('/usr/lib/packagename/foo.rb')
or this::
require '/usr/lib/packagename/foo.rb'
Foo::run()
or this::
system('/usr/bin/ruby /usr/lib/packagename/foo.rb')
The first example needs a shebang. The second example should be mode 0644
and you could place them in /usr/share/packagename/. The third example is
in a grey area since it's "data of the ruby interpreter" and can be mode
0644 but it's really not functionally different from the first example. I'd
say that based on upstream's assertion it's probably best to move it to
/usr/share/packagename, mode 0644, no she-bang. (But in this case "best" is
an ideal and there's room for you to make a case for treating it as one of
the other two cases as well).
-Toshio
pgpUDtWvHpxLv.pgp
Description: PGP signature
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
scripts without she-bang in /usr/lib/packagename/
I have a package that contains ruby scripts in /usr/lib/packagename/ These scripts are only called/included via other binaries. If I do not make these executable, then rpmlint complains about non-executable content in /usr/lib/packagename/ and suggests I move it to /usr/share/packagename. If I make them executable, then it complains about missing she-bang. upstream thinks there is no problem and says the scripts should never be executed on their own, so no she-bang should be there. Fedora does not allow executing from /usr/share. Should I just ignore rpmlint for this case? Paul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Bug 754725] Using Yumex - some updates throw error - ERROR with transaction check vs depsolve
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=754725 Iain Arnell changed: What|Removed |Added CC||iarn...@gmail.com, ||t...@rasmil.dk Component|perl-WWW-Mechanize |yumex AssignedTo|cw...@alumni.drew.edu |t...@rasmil.dk --- Comment #1 from Iain Arnell 2011-11-17 11:44:22 EST --- It must be a problem with yumex, not the perl packages. perl-HTML-Form-6.00-5.fc16 is available and provides "perl(HTML::Form) = 6.00". Yum itself has no problem to resolve the dependency (and installing xmltv (from rpmfusion-free) also works for me with yum): # yum install perl-WWW-Mechanize Loaded plugins: langpacks, presto Setting up Install Process Resolving Dependencies --> Running transaction check ---> Package perl-WWW-Mechanize.noarch 0:1.68-2.fc16 will be installed --> Processing Dependency: perl(HTML::Form) >= 1.00 for package: perl-WWW-Mechanize-1.68-2.fc16.noarch --> Running transaction check ---> Package perl-HTML-Form.noarch 0:6.00-5.fc16 will be installed --> Finished Dependency Resolution Dependencies Resolved == Package Arch Version RepositorySize == Installing: perl-WWW-Mechanize noarch 1.68-2.fc16 fedora 146 k Installing for dependencies: perl-HTML-Form noarch 6.00-5.fc16 fedora26 k Transaction Summary == Install 2 Packages Total download size: 173 k Installed size: 173 k Is this ok [y/N]: y Downloading Packages: (1/2): perl-HTML-Form-6.00-5.fc16.noarch.rpm | 26 kB 00:00 (2/2): perl-WWW-Mechanize-1.68-2.fc16.noarch.rpm | 146 kB 00:00 -- Total 143 kB/s | 173 kB 00:01 Running Transaction Check Running Transaction Test Transaction Test Succeeded Running Transaction Installing : perl-HTML-Form-6.00-5.fc16.noarch 1/2 Installing : perl-WWW-Mechanize-1.68-2.fc16.noarch 2/2 Installed: perl-WWW-Mechanize.noarch 0:1.68-2.fc16 Dependency Installed: perl-HTML-Form.noarch 0:6.00-5.fc16 Complete! -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. -- 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: cisco vpn because of ipsec over tcp
On Thu, 2011-11-17 at 11:10 -0500, Benjamin LaHaise wrote: > Why not use a tun/tap interface set up with a private ip address which the > vpn application causes to be masqueraded by the host? That should work and > be portable across all kernel versions. Yeah, that's one of of the options. But still you have to set up NAT on the host. And make sure you don't conflict with any IP address ranges which might appear on local networks, or on the VPN. It doesn't really meet the "set it up nicely" criterion :) If you can screw with iptables rules to set up NAT, you might as well just screw with iptables rules to block and capture the TCP packets you want. Either way, it's a pain in the arse. -- dwmw2 smime.p7s Description: S/MIME cryptographic signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Need help with bundled lib issue for OpenColorIO
On Thu, Nov 17, 2011 at 09:11:06AM -0600, Richard Shaw wrote:
> On Thu, Nov 17, 2011 at 8:55 AM, Jon Ciesla wrote:
> >
> >> I'm working on packaging OpenColorIO for Fedora and ran into an issue
> >> with bundled libraries.
> >>
> >> The project is currently statically compiling in yaml-cpp, tinyxml,
> >> and lcms. Upstream doesn't have a problem with unbundling lcms, but is
> >> not sure about the other two, here's his explination:
> >>
> >> hmmm some of the things in ext are not exposed in the public OCIO
> >> API; and not being a build expert I'd prefer to not expose additional
> >> runtime library dependencies. (tinyxml + yamlcpp, for example).
> >>
> >> With your implementation, on a fedora build that had one of these
> >> libraries installed, would you link to the xml / yaml so(s), or would
> >> it use the .a statically at build time? I'd hate to have the
> >> dependancies in the core library change depending on build options.
> >> What if I pulled in these two libraries into 'core' as source files?
> >> (it used to be this way, actually). I'm fine with picking up lcms, etc
> >> externally. But i'd like core to be self-contained...
> >> ---
> >>
> >> Are there technical reasons these libraries can not be unbundled?
> >
> > Only if he's significantly modifying the bundled libs and upstream won't
> > take the changes. If you unbundle and build against the system versions,
> > and it works, that's what you need to do. Always link dynamically if at
> > all possible.
>
> Ok, so the public/private API's won't be a problem?
>
I'm not quite sure what he means by public/private API. If he's saying that
the end user doesn't see the xml and yaml libraries's APIs that seems like
it's tangential to the issue.
If he's talking about shielding the user from having to download and install
those libraries separately, the strategy we like upstreams to follow is to
keep the bundled code when they ship but at build time choose whether to use
the bundled library or the system library.
Since we have rpm packages that keep dependency information and yum which
does depsolving, the end user would not have to worry about the additional
dependencies on libraries when installing our package -- yum install
OpenColorIO would pull the proper dependencies automatically. When an
OpenColorIO user downloads the package and builds from source, they can use
the bundled versions.
For his question about .so vs .a and pulling the source files in -- the
problems that we're trying to avoid are the bundled libraries having issues
(especially, but not limited to security issues) that need patching. If
there's a single system copy in a dynamic library, there's one package that
we have to update to fix this. If there's static libraries involved, then
we need to rebuild the library package and then find the packages that are
linked statically and rebuild them. If there's libraries that are bundled,
then we have to recompile the system library, we have to find what software
has bundled the libraries (hopefully we've already identified them as in
this case), if there's patches nad changes to the bundled library we have to
merge those with the new version from upstream that fixes the issues, and
then we have to rebuild and reship those libraries.
So for us, the ideal is to link against the .so's and let the package
manager do the work of pulling the right packages for the end user. If
upstream wishes to ship the libraries as a supplement for those who are not
getting them from upstream, that's fine but making it work for both cases
makes for the best experience for the users.
> He did mention they were patched, some of it for build reasons (no
> problem) but some of it was to make it work. He's going to check to
> see if those patches have made their way into upstream.
>
If upstream hasn't taken them yet, it's possible that our packages could
carry the changes. It depends on the maintainer of the library package,
whether the upstream is going to merge the changes eventually, and whether
they cause incompatibilities. Something to keep in mind.
> The last problem is a strange one. They have a library, PyOpenColorIO
> that provides both C++ symbols, but also python bindings. I assume
> they need to go in /usr/lib{,64} but should they also get symlinked to
> /usr/lib{,64}/pythonX.X/site-packages?
>
Yeah, that is an interesting one. Typically, libraries for C and elf shared
objects that are python extensions are kept in separate files. From your
description, a symlink would be appropriate here.
-Toshio
pgpULoqWBr1Nw.pgp
Description: PGP signature
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
[Bug 754725] Using Yumex - some updates throw error - ERROR with transaction check vs depsolve
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=754725 Bill Nottingham changed: What|Removed |Added CC||cw...@alumni.drew.edu, ||fedora-perl-devel-list@redh ||at.com Component|distribution|perl-WWW-Mechanize AssignedTo|nott...@redhat.com |cw...@alumni.drew.edu QAContact|nott...@redhat.com |extras...@fedoraproject.org -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. -- 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: cisco vpn because of ipsec over tcp
On Wed, Nov 16, 2011 at 12:49:41PM +, David Woodhouse wrote: > We *have* had Cisco's IPSec over TCP working; it's not particularly > difficult. However, we never really worked out how to make it work > nicely on Linux; the kernel really *really* wants to eat all TCP packets > and will give a TCP RST to any connection it doesn't think is open. Any > mechanism to effectively operate TCP in userspace, which is what we need > to do, would be very much frowned upon. Why not use a tun/tap interface set up with a private ip address which the vpn application causes to be masqueraded by the host? That should work and be portable across all kernel versions. -ben -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: hdf5-1.8.8 in rawhide
On 11/17/2011 02:46 AM, Jussi Lehtola wrote:
> On Wed, 16 Nov 2011 17:08:27 -0700
> Orion Poplawski wrote:
>> hdf5-1.8.8 is now in rawhide. Any packages that build against hdf5
>> need to be rebuilt. I've already done R-hdf5 and gdl. Note that
>> there is no soname bump but the hdf5 library checks that the runtime
>> and compile time versions are the same and aborts if they are not.
>> Probably good to have all hdf5 users do a:
>>
>> Require: hdf5 = 1.8.8
>
> .. so please just add an rpm macro in the hdf package, that handles
> numbering automatically, so that we can just
>
> Requires: hdf5 = %{hdf5ver}
>
> in the related packages.
Done:
Requires: hdf5 = %{_hdf5_version}
This is only in rawhide at the moment.
--
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA/CoRA DivisionFAX: 303-415-9702
3380 Mitchell Lane or...@cora.nwra.com
Boulder, CO 80301 http://www.cora.nwra.com
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Unannounced ABI bump in rawhide: quvi
quvi 0.4.0 is both an ABI and API break. See the rawhide report for details. Nicoleau, please remember to announce changes that may affect others: https://fedoraproject.org/wiki/Package_maintainer_responsibilities#Notify_others_of_changes_that_may_affect_their_packages - ajax signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Need help with bundled lib issue for OpenColorIO
On Thu, Nov 17, 2011 at 8:55 AM, Jon Ciesla wrote:
>
>> I'm working on packaging OpenColorIO for Fedora and ran into an issue
>> with bundled libraries.
>>
>> The project is currently statically compiling in yaml-cpp, tinyxml,
>> and lcms. Upstream doesn't have a problem with unbundling lcms, but is
>> not sure about the other two, here's his explination:
>>
>> hmmm some of the things in ext are not exposed in the public OCIO
>> API; and not being a build expert I'd prefer to not expose additional
>> runtime library dependencies. (tinyxml + yamlcpp, for example).
>>
>> With your implementation, on a fedora build that had one of these
>> libraries installed, would you link to the xml / yaml so(s), or would
>> it use the .a statically at build time? I'd hate to have the
>> dependancies in the core library change depending on build options.
>> What if I pulled in these two libraries into 'core' as source files?
>> (it used to be this way, actually). I'm fine with picking up lcms, etc
>> externally. But i'd like core to be self-contained...
>> ---
>>
>> Are there technical reasons these libraries can not be unbundled?
>
> Only if he's significantly modifying the bundled libs and upstream won't
> take the changes. If you unbundle and build against the system versions,
> and it works, that's what you need to do. Always link dynamically if at
> all possible.
Ok, so the public/private API's won't be a problem?
He did mention they were patched, some of it for build reasons (no
problem) but some of it was to make it work. He's going to check to
see if those patches have made their way into upstream.
The last problem is a strange one. They have a library, PyOpenColorIO
that provides both C++ symbols, but also python bindings. I assume
they need to go in /usr/lib{,64} but should they also get symlinked to
/usr/lib{,64}/pythonX.X/site-packages?
Thanks,
Richard
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Need help with bundled lib issue for OpenColorIO
> I'm working on packaging OpenColorIO for Fedora and ran into an issue > with bundled libraries. > > The project is currently statically compiling in yaml-cpp, tinyxml, > and lcms. Upstream doesn't have a problem with unbundling lcms, but is > not sure about the other two, here's his explination: > > hmmm some of the things in ext are not exposed in the public OCIO > API; and not being a build expert I'd prefer to not expose additional > runtime library dependencies. (tinyxml + yamlcpp, for example). > > With your implementation, on a fedora build that had one of these > libraries installed, would you link to the xml / yaml so(s), or would > it use the .a statically at build time? I'd hate to have the > dependancies in the core library change depending on build options. > What if I pulled in these two libraries into 'core' as source files? > (it used to be this way, actually). I'm fine with picking up lcms, etc > externally. But i'd like core to be self-contained... > --- > > Are there technical reasons these libraries can not be unbundled? Only if he's significantly modifying the bundled libs and upstream won't take the changes. If you unbundle and build against the system versions, and it works, that's what you need to do. Always link dynamically if at all possible. -J > Thanks, > Richard > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel > -- in your fear, seek only peace in your fear, seek only love -d. bowie -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Need help with bundled lib issue for OpenColorIO
I'm working on packaging OpenColorIO for Fedora and ran into an issue with bundled libraries. The project is currently statically compiling in yaml-cpp, tinyxml, and lcms. Upstream doesn't have a problem with unbundling lcms, but is not sure about the other two, here's his explination: hmmm some of the things in ext are not exposed in the public OCIO API; and not being a build expert I'd prefer to not expose additional runtime library dependencies. (tinyxml + yamlcpp, for example). With your implementation, on a fedora build that had one of these libraries installed, would you link to the xml / yaml so(s), or would it use the .a statically at build time? I'd hate to have the dependancies in the core library change depending on build options. What if I pulled in these two libraries into 'core' as source files? (it used to be this way, actually). I'm fine with picking up lcms, etc externally. But i'd like core to be self-contained... --- Are there technical reasons these libraries can not be unbundled? Thanks, Richard -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: hdf5-1.8.8 in rawhide
On Wed, 16 Nov 2011 17:08:27 -0700
Orion Poplawski wrote:
> hdf5-1.8.8 is now in rawhide. Any packages that build against hdf5
> need to be rebuilt. I've already done R-hdf5 and gdl. Note that
> there is no soname bump but the hdf5 library checks that the runtime
> and compile time versions are the same and aborts if they are not.
> Probably good to have all hdf5 users do a:
>
> Require: hdf5 = 1.8.8
.. so please just add an rpm macro in the hdf package, that handles
numbering automatically, so that we can just
Requires: hdf5 = %{hdf5ver}
in the related packages.
--
Jussi Lehtola
Fedora Project Contributor
jussileht...@fedoraproject.org
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
