Re: Update ImageMagick
On 07/04/2011 07:52 PM, Nils Philippsen wrote:
On Mon, 2011-07-04 at 16:33 +0200, Nils Philippsen wrote:
On Mon, 2011-07-04 at 18:10 +0400, Pavel Alexeev (aka Pahan-Hubbitus)
wrote:
Now ImageMagick built against new gcc.
Great, thanks!
Now that I've rebuilt rss-glx against the new ImageMagick version I see
that it has the same library versions, libMagick{Core,Wand}.so.4 -- it
this rebuilding of our packages really necessary?
Nils
If so, it is on your choose.
But in any case ! strongly recommend do that because upstream maintainer
does not carefully handle soname bump -
http://www.mail-archive.com/debian-bugs-dist@lists.debian.org/msg736218.html
--
With best wishes, Pavel Alexeev (aka Pahan-Hubbitus). For fast contact
with me use jabber: hubbi...@jabber.ru
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: vsftpd in the news
On Tue, 05 Jul 2011 17:05:45 -0500, MC (Michael) wrote: Some packagers do upload the detached sig and add it to the spec as another Source file URL. Great! Except I haven't done so. I wasn't required to submit a signature for my package nor does the Package Guildline pages refer to doing so. Might be worth someone's time to mention it on the wiki (who knows about this functionality). It isn't any functionality. It is just possible to place a tarball and its detached GPG sig file in the source RPM package for anyone who may want to verify the sig manually at some point in time. Verifying detached tarball sigs isn't trivial or 100% safe anyway. One needs to be very familiar with the signer's key(s). Else the risk is too high that a user simply fetches a needed key from a key server without applying extra care. And for a sufficiently large tarball of a project with N1 devs, has the signer been able to actually verify all source code changes prior to signing the tarball? Or is the signature only used to flag a package as coming from a trusted project developer without any additional guarantees? A tarball sig is just one layer of safety, but no ultimate protection. The uploaded tarball checksum enters the sources file in git, and any tarball downloaded from the lookaside cache MUST match that checksum. Else it wouldn't be downloaded and used. Source RPM build in koji would fail. This is just a checksum against the tarball that enters the lookaside cache. Yes, I know about this. A malicious package could have been uploaded to the lookaside cache, however. This leads to demanding everyone have signatures available, but what do you do about SVN/Git checkouts or projects that don't wish to provide signatures? Obviously, one needs to be very careful, skim over diffs, monitor commits regularly, archive snapshots regularly, be familiar with upstream release habits. Upstream also needs to do that, to avoid that a compromised account from a committer is used to infiltrate the project. If a source code repository is modified without permission and no developer (or release manager) notices it, would the person adding the tarball sig notice it? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: vsftpd in the news
On Tue, 05 Jul 2011 21:02:33 -0700, AW (Adam) wrote: There's a few cavets that have been mentioned in this thread that would make this functionality mostly pointless to try and implement. 1) Not all packages include gpg signatures. a) not everyone knows they can include them b) SCM checkouts don't have signatures c) some projects don't use them 2) We don't have a system to validate a gpg signature in place. My understanding of GPG is that we would need to house all the public keys to validate against. Nothing like this exists. I'm lazy and don't feel like creating such a system. :) We're stuck with the lookaside cache checksum for now. 1) doesn't really matter. So we get some assurance for some packages, not all; it's still better than none. Don't make the perfect the enemy of the good. 2) ditto - we can 'house' them in so far as including them as package sources. If they aren't included then don't run the check. If they are, run the check... If we include the whole show in the src.rpm, how does that add any safety? Doesn't that make it easier to compromise the src.rpm by replacing tarball, sig, and key? How does the check know whether an included key is the right one and can be trusted, too? Even included tarball sigs would need another layer, such as the package creator signing off all files (large or compressed patches, too!) with either a personal key or with a project signing-server. Just another layer, though... -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: vsftpd in the news
On Wed, Jul 6, 2011 at 9:19 AM, Michael Schwendt mschwe...@gmail.com wrote: On Tue, 05 Jul 2011 21:02:33 -0700, AW (Adam) wrote: 2) We don't have a system to validate a gpg signature in place. My understanding of GPG is that we would need to house all the public keys to validate against. Nothing like this exists. I'm lazy and don't feel like creating such a system. :) 2) ditto - we can 'house' them in so far as including them as package sources. If they aren't included then don't run the check. If they are, run the check... If we include the whole show in the src.rpm, how does that add any safety? It can protect Fedora against substituted upstream tarballs (i.e. if the new upstream version has an incorrect signature, we would notice). Doesn't that make it easier to compromise the src.rpm by replacing tarball, sig, and key? That's protecting Fedora users against substituted Fedora RPMs, which is quite orthogonal to protecting Fedora against upstream tarballs. How does the check know whether an included key is the right one and can be trusted, too? The package maintainer can decide who is trusted to publish upstream releases, and list the trusted keys in a config file. Even included tarball sigs would need another layer, such as the package creator signing off all files (large or compressed patches, too!) with either a personal key or with a project signing-server. Just another layer, though... Yes, we could require gpg-signed git commits; but note that this wouldn't be a protection against hijacked Fedora accounts, IMHO the most likely avenue of attack. gpg-signed git commits would protect the integrity/verifiability of the git history (e.g. against attacks directly on the git repo storage, or against an attacker having root on the Fedora servers) - but only as long as the Fedora account system (housing the public keys of package maintainers) would not be compromised as wel. Mirek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: vsftpd in the news
06.07.2011, 16:07, Michael Schwendt mschwe...@gmail.com: And for a sufficiently large tarball of a project with N1 devs, has the signer been able to actually verify all source code changes prior to signing the tarball? Or is the signature only used to flag a package as coming from a trusted project developer without any additional guarantees? A tarball sig is just one layer of safety, but no ultimate protection. The uploaded tarball checksum enters the sources file in git, and any tarball downloaded from the lookaside cache MUST match that checksum. Else it wouldn't be downloaded and used. Source RPM build in koji would fail. This is just a checksum against the tarball that enters the lookaside cache. Yes, I know about this. A malicious package could have been uploaded to the lookaside cache, however. This leads to demanding everyone have signatures available, but what do you do about SVN/Git checkouts or projects that don't wish to provide signatures? Obviously, one needs to be very careful, skim over diffs, monitor commits regularly, archive snapshots regularly, be familiar with upstream release habits. Upstream also needs to do that, to avoid that a compromised account from a committer is used to infiltrate the project. If a source code repository is modified without permission and no developer (or release manager) notices it, would the person adding the tarball sig notice it? The developer of vsftpd didn't notice the change, but still there was early prevention possible. The issue is *one* of the ways source code can be exploited, and checking the gpg signatures for the projects that allow it is a measure against the particular kind of attack. Literally, it would close one vulnerability in the distro. Which is enough. -- Best regards, Misha Shnurapet, Fedora Project Contributor Email: shnurapet AT fedoraproject.org, IRC: misha on freenode https://fedoraproject.org/wiki/shnurapet, GPG: 00217306 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: vsftpd in the news
On Wed, 6 Jul 2011 09:48:24 +0200, MT (Miloslav) wrote: On Tue, 05 Jul 2011 21:02:33 -0700, AW (Adam) wrote: 2) We don't have a system to validate a gpg signature in place. My understanding of GPG is that we would need to house all the public keys to validate against. Nothing like this exists. I'm lazy and don't feel like creating such a system. :) 2) ditto - we can 'house' them in so far as including them as package sources. If they aren't included then don't run the check. If they are, run the check... If we include the whole show in the src.rpm, how does that add any safety? It can protect Fedora against substituted upstream tarballs (i.e. if the new upstream version has an incorrect signature, we would notice). The packager should have noticed already. If the sig file is added to the src.rpm and the public key has been added to it [a long time] before, all AutoQA would add is to detect the case when the packager added a new tarball+sig without verifying it beforehand. Right? Doesn't that make it easier to compromise the src.rpm by replacing tarball, sig, and key? That's protecting Fedora users against substituted Fedora RPMs, which is quite orthogonal to protecting Fedora against upstream tarballs. If it's possible to hack a web page and replace a tarball, it would also be possible to replace a detached sig file (or even add a faked one for the first time and pretend that it's a new feature of the release process). It wouldn't be the first project where the signer and/or the signing key has changed, and where the downloader needs to decide on whether to trust the key that has been used. That is, not just use --recv-keys to fetch it from a key server. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: vsftpd in the news
On Wed, Jul 6, 2011 at 10:43 AM, Michael Schwendt mschwe...@gmail.com wrote: On Wed, 6 Jul 2011 09:48:24 +0200, MT (Miloslav) wrote: If we include the whole show in the src.rpm, how does that add any safety? It can protect Fedora against substituted upstream tarballs (i.e. if the new upstream version has an incorrect signature, we would notice). The packager should have noticed already. If the sig file is added to the src.rpm and the public key has been added to it [a long time] before, all AutoQA would add is to detect the case when the packager added a new tarball+sig without verifying it beforehand. Right? Exactly. If it's possible to hack a web page and replace a tarball, it would also be possible to replace a detached sig file (or even add a faked one for the first time and pretend that it's a new feature of the release process). It wouldn't be the first project where the signer and/or the signing key has changed, and where the downloader needs to decide on whether to trust the key that has been used. That is, not just use --recv-keys to fetch it from a key server. That's an interesting subproblem, especially if the signing key were lost. In practice, handling a key change can probably be done reasonably securely even in such cases, e.g. by announcing the key change on the project's mailing list where the holder of the previous key and the project's governing body would have to notice the announcement, and waiting long enough to allow for the project members to contradict the announcement. From the Fedora point of view, we don't need to do anything special - the package maintainer would or would not update the list of trusted tarball signers depending on the packager's view of the situation. Mirek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: cups service gone walkabouts?
On 06/07/11 10:19, Paul F. Johnson wrote: It seems that after yesterdays (5th July) mammoth rawhide update, that the cups daemon has vanished from /etc/init.d - any idea if this is just an oversight? I would guess (given that Lennart used it as his example in his recent article) that it has been converted to be a native systemd service. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd: Tagging /dev/virtio-ports/* for systemd
On Tue, Jul 05, 2011 at 08:36:42PM +0200, Lennart Poettering wrote:
On Tue, 05.07.11 16:54, Daniel P. Berrange (berra...@redhat.com) wrote:
Heya,
On Tue, Jul 05, 2011 at 04:47:18PM +0100, Richard W.M. Jones wrote:
[Is there a Fedora-specific systemd list? Not that I can find.]
We'd like to request that virtio-serial devices (/dev/virtio-ports/*)
are tagged so we can use them as systemd devices. Dan Berrange thinks
the right incantation is to add:
SUBSYSTEM==virtio-ports, TAG+=systemd
to /lib/udev/rules.d/99-systemd.rules
The goal is that we want to automagically run /usr/sbin/guestfsd
when /dev/virtio-ports/org.libguestfs.channel.0 is present. For
this I believe we need to have a '.device' unit for the virtio-port
device populated from the above udev rule, so we can in turn have a
guestfsd.service unit looking like:
I think adding such a rule to systemd's unit file is not a bad idea, but
since the use case here is very specific to your app, another option
would be to add an app-specific udev rule for this. (See below)
[Unit]
Description=libguestfs management daemon
BindTo=dev-virtio\x2dports-org.libguestfs.channel.0.device
After=dev-virtio\x2dports-org.libguestfs.channel.0.device
[Service]
ExecStart=-/usr/sbin/guestfsd
Prefixing the binary path with - will result in the exit code of
guestfsd be ignored, i.e. we wouldn't put the service into failed state
if it crashes (or exits otherwise abnormally). I'd encourage never to
prefix with - unless you have a really good reason to.
Restart=always
RestartSec=0
[Install]
WantedBy=multi-user.target
If you use WantedBy=multi-user.target then this unit would be started
at boot, and delayed until the device in question shows up. If it never
shows up (for example because you boot on bare metal), then it would
have to timeout, which wouldn't be particularly pretty.
Yeah, we don't really want a timeout on bare metal, or if the guest
doesn't have the device enabled.
I wonder if it wouldn't be nicer to use the device showing up as _only_
trigger to spawn the service. This would be nicer I think because it
would spawn the service only if run in a VM. If you run the machine on
bare metal, then it wouldn't be started at all, and would not have to
timeout. (And if I grok this properly, then the virtio serial ports are
even hotpluggable, which makes this even more interesting) To implement
a scheme like that, you'd just ship a udev rules file which you install
to /lib/udev/rules/99-guestfs.rules with contents
like this:
SUBSYSTEM==virtio-ports, ATTR{name}==org.libguestfs.channel.0,
TAG+=systemd, ENV{SYSTEMD_WANTS}=guestfsd.service
(untested, I hope the match is right)
It's up to you whether you prefer the spawn unconditionally but wait
for the device to show up approach or my suggestion of spawn if and
when the device shows up.
We do in fact want the latter 'spawn if and when the device shows up',
so we'll have a go with the udev rule you suggest above.
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 :|
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: cups service gone walkabouts?
Hi, It seems that after yesterdays (5th July) mammoth rawhide update, that the cups daemon has vanished from /etc/init.d - any idea if this is just an oversight? I would guess (given that Lennart used it as his example in his recent article) that it has been converted to be a native systemd service. Ah. Looks like I may need to bz it as unless I run /usr/sbin/cupsd -F from a terminal, the service isn't starting. s-c-services and s-c-printer isn't showing anything. Should I put it under cups or systemd? PFJ -- Vertraue mir, ich weiss, was ich mache... -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: cups service gone walkabouts?
On Wed, 06 Jul 2011 10:19:46 +0100 Paul F. Johnson wrote: It seems that after yesterdays (5th July) mammoth rawhide update, that the cups daemon has vanished from /etc/init.d - any idea if this is just an oversight? * Wed Jun 29 2011 Tim Waugh twa...@redhat.com 1:1.5-0.9.rc1 - Ship systemd service unit instead of SysV initscript (bug #690766). -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: cups service gone walkabouts?
On 06/07/11 10:25, Paul F. Johnson wrote: I would guess (given that Lennart used it as his example in his recent article) that it has been converted to be a native systemd service. Ah. Looks like I may need to bz it as unless I run /usr/sbin/cupsd -F from a terminal, the service isn't starting. s-c-services and s-c-printer isn't showing anything. Well first of all I'd check it's enabled as I believe policy is that the enabled/disabled state of a service is not carried over when it migrates from svsvinit to systemd. So a systemctl enable cups.service might be the best thing to try first - certainly my rawhide VM seems to have had it disabled. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: cups service gone walkabouts?
On Wed, 2011-07-06 at 10:19 +0100, Paul F. Johnson wrote: Hi, It seems that after yesterdays (5th July) mammoth rawhide update, that the cups daemon has vanished from /etc/init.d - any idea if this is just an oversight? Looks like it migrated to native systemd configuration: http://pkgs.fedoraproject.org/gitweb/?p=cups.git;a=commitdiff;h=b7d9a11244c22bd7e2ea4590f78a7a22852871b2 -- Mathieu -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
OpenMPI, Emacs and libotf problems
Hello all: I am hoping it is OK to discuss this here. I came across this problem when I was building a custom spin where the kickstart file installs 'openmpi' before 'emacs'. When I start emacs, here is what I get: $emacs emacs: error while loading shared libraries: libotf.so.0: cannot open shared object file: No such file or directory So, this library is missing. However, this should have been installed as its a dependency, right? It can be seen that there are two providers listed for libotf.so.0. Since 'openmpi' was already installed, so it didn't bother installing 'libotf'. I could simulate the scenario on a Fedora 15 installation: Step1: Dependency listing - $yum deplist emacs dependency: libotf.so.0 provider: openmpi.i686 1.5-3.fc15 provider: libotf.i686 0.9.12-2.fc15 To verify this scenario, the next step attempts to install emacs on a machine without emacs, libotf and openmpi: Step 2: Installing emacs -- [gene@soma ~]$ sudo yum install emacs Loaded plugins: langpacks, presto, refresh-packagekit Setting up Install Process Resolving Dependencies -- Running transaction check --- Package emacs.i686 1:23.2-19.fc15 will be installed -- Processing Dependency: libotf.so.0 for package: 1:emacs-23.2-19.fc15.i686 -- Running transaction check --- Package libotf.i686 0:0.9.12-2.fc15 will be installed -- Finished Dependency Resolution Dependencies Resolved === PackageArch Version Repository Size === Installing: emacs i686 1:23.2-19.fc15 updates 2.0 M Installing for dependencies: libotf i686 0.9.12-2.fc15 fedora 82 k Transaction Summary === Install 2 Package(s) Total download size: 2.1 M all good here. (I don't proceed with the install) Step 3: Installing openmpi -- Next, I just install openmpi, which is listed as a provider for libotf.so.0: [gene@soma ~]$ sudo yum install openmpi Loaded plugins: langpacks, presto, refresh-packagekit Setting up Install Process Resolving Dependencies -- Running transaction check --- Package openmpi.i686 0:1.5-3.fc15 will be installed -- Finished Dependency Resolution Dependencies Resolved === Package Arch Version Repository Size === Installing: openmpi i686 1.5-3.fc15 fedora 1.7 M Transaction Summary === Install 1 Package(s) Total download size: 1.7 M Installed size: 6.7 M Install done. Step 4: Installing Emacs after installing openmpi --- [gene@soma ~]$ sudo yum install emacs Loaded plugins: langpacks, presto, refresh-packagekit Setting up Install Process Resolving Dependencies -- Running transaction check --- Package emacs.i686 1:23.2-19.fc15 will be installed -- Finished Dependency Resolution Dependencies Resolved === Package Arch Version Repository Size === Installing: emacs i686 1:23.2-19.fc15 updates 2.0 M Transaction Summary === Install 1 Package(s) Total download size: 2.0 M Installed size: 6.5 M Is this ok [y/N]: y Downloading Packages: Setting up and reading Presto delta metadata Processing delta metadata Package(s) data still to download: 2.0 M emacs-23.2-19.fc15.i686.rpm | 2.0 MB 00:00 Running rpm_check_debug Running Transaction Test Transaction Test Succeeded Running Transaction Installing : 1:emacs-23.2-19.fc15.i686 1/1 Installed: emacs.i686 1:23.2-19.fc15 It doesn;t list the dependeny anymore on libotf.so.0, since openmpi is already installed. And the result: $emacs emacs: error while loading shared libraries: libotf.so.0: cannot open shared object file: No such file or directory I also noted this discrepancy: $sudo yum whatprovides libotf.so.0 Loaded plugins: langpacks, presto, refresh-packagekit openmpi-1.5-3.fc15.i686 : Open Message Passing Interface Repo: fedora Matched from: Other : libotf.so.0 libotf-0.9.12-2.fc15.i686 : A Library for
Re: cups service gone walkabouts?
On Wed, 2011-07-06 at 10:30 +0100, Tom Hughes wrote: Well first of all I'd check it's enabled as I believe policy is that the enabled/disabled state of a service is not carried over when it migrates from svsvinit to systemd. Correct, and I haven't pursued getting an exception for cups so that it can automatically be enabled. Did we decide in the end that default service enabling should happen as part of a spin's kickstart, or does it need to be in the package? Tim. */ 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: systemd: Tagging /dev/virtio-ports/* for systemd
On Tue, Jul 05, 2011 at 08:36:42PM +0200, Lennart Poettering wrote: On Tue, 05.07.11 16:54, Daniel P. Berrange (berra...@redhat.com) wrote: [Service] ExecStart=-/usr/sbin/guestfsd Prefixing the binary path with - will result in the exit code of guestfsd be ignored, i.e. we wouldn't put the service into failed state if it crashes (or exits otherwise abnormally). I'd encourage never to prefix with - unless you have a really good reason to. In this case, I think we do. The daemon only handles one connection at a time (that is the nature of virtio-serial ports) and it will exit with EXIT_FAILURE if an error is read in the protocol. This can happen in some legitimate-ish cases, eg. if the host side disconnects without properly closing the connection. But what we'd want to avoid is the case where the daemon dies during startup, and we get into a loop repeatedly relaunching the daemon. The question is, does systemd implement respawn throttling like inetd? Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://et.redhat.com/~rjones/virt-top -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd: Tagging /dev/virtio-ports/* for systemd
I haven't tested this yet .. will do later today. But comments welcome on: http://pkgs.fedoraproject.org/gitweb/?p=libguestfs.git;a=blob;f=99-guestfsd.rules;h=ab4f6800bbd847307aceb2cb52e984524eaee52c;hb=HEAD http://pkgs.fedoraproject.org/gitweb/?p=libguestfs.git;a=blob;f=guestfsd.service;h=482d1e2bf1fb1c791e3adfe3f58716c38edb6b3d;hb=HEAD http://pkgs.fedoraproject.org/gitweb/?p=libguestfs.git;a=blob;f=libguestfs.spec;h=c78a5f75349fd34944c7a5eb637050ed6bf65c1e;hb=HEAD#l330 http://pkgs.fedoraproject.org/gitweb/?p=libguestfs.git;a=blob;f=libguestfs.spec;h=c78a5f75349fd34944c7a5eb637050ed6bf65c1e;hb=HEAD#l652 http://pkgs.fedoraproject.org/gitweb/?p=libguestfs.git;a=blob;f=libguestfs.spec;h=c78a5f75349fd34944c7a5eb637050ed6bf65c1e;hb=HEAD#l755 Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones New in Fedora 11: Fedora Windows cross-compiler. Compile Windows programs, test, and build Windows installers. Over 70 libraries supprt'd http://fedoraproject.org/wiki/MinGW http://www.annexia.org/fedora_mingw -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: cups service gone walkabouts?
On 07/06/2011 11:18 AM, Tim Waugh wrote: On Wed, 2011-07-06 at 10:30 +0100, Tom Hughes wrote: Well first of all I'd check it's enabled as I believe policy is that the enabled/disabled state of a service is not carried over when it migrates from svsvinit to systemd. Correct, and I haven't pursued getting an exception for cups so that it can automatically be enabled. Did we decide in the end that default service enabling should happen as part of a spin's kickstart, or does it need to be in the package? Hum.. I thought with Lennart patch/setup on his blog the only case you need to enable cups is if you are going to be running centralized printer server which in that case the admin himself would enabled it hence we would not have to have it enabled by default... JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd: Tagging /dev/virtio-ports/* for systemd
On 07/06/2011 11:21 AM, Richard W.M. Jones wrote: On Tue, Jul 05, 2011 at 08:36:42PM +0200, Lennart Poettering wrote: On Tue, 05.07.11 16:54, Daniel P. Berrange (berra...@redhat.com) wrote: [Service] ExecStart=-/usr/sbin/guestfsd Prefixing the binary path with - will result in the exit code of guestfsd be ignored, i.e. we wouldn't put the service into failed state if it crashes (or exits otherwise abnormally). I'd encourage never to prefix with - unless you have a really good reason to. In this case, I think we do. The daemon only handles one connection at a time (that is the nature of virtio-serial ports) and it will exit with EXIT_FAILURE if an error is read in the protocol. This can happen in some legitimate-ish cases, eg. if the host side disconnects without properly closing the connection. But what we'd want to avoid is the case where the daemon dies during startup, and we get into a loop repeatedly relaunching the daemon. The question is, does systemd implement respawn throttling like inetd? Hum Would Restart= not suffice as in.. Restart=on-failure Or Restart=on-abort from man systemd.service Restart= Configures whether the main service process shall be restarted when it exits. Takes one of no, on-success, on-failure, on-abort or always. If set to no (the default) the service will not be restarted when it exits. If set to on-success it will be restarted only when it exited cleanly, i.e. terminated with an exit code of 0. If set to on-failure it will be restarted only when it exited with an exit code not equalling 0, or when terminated by a signal. If set to on-abort it will be restarted only if it exits due to reception of an uncaught signal. If set to always the service will be restarted regardless whether it exited cleanly or not, or got terminated abnormally by a signal JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: cups service gone walkabouts?
On Wed, 2011-07-06 at 11:32 +, Jóhann B. Guðmundsson wrote: I thought with Lennart patch/setup on his blog the only case you need to enable cups is if you are going to be running centralized printer server which in that case the admin himself would enabled it hence we would not have to have it enabled by default... Yes, you're quite right, my mistake. Tim. */ 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: systemd: Tagging /dev/virtio-ports/* for systemd
On Wed, 06.07.11 10:22, Daniel P. Berrange (berra...@redhat.com) wrote: So, I am a bit confused now after reading this: http://fedoraproject.org/wiki/Features/VirtioSerial How does /dev/hvcxxx relate to these virtio ports? hvc ports are tagged systemd anyway in udev, so if this is the same thing, why do we have to tag the virtio ports too? Can you explain how hvc and virtio relate to each other and under which kernel device names they show up in udev and how they correspond? In QEMU, there is one PCI device virtio-serial-pci. In QEMU's view this device is a bus to which we then attach zero or more 'virtconsole' or 'virtserialport' devices. The 'virtconsole' device is a paravirt text console, which appears as /dev/hvcNNN in the guest. These are intended for interactive login and would be expected to run a mingetty/agetty process. Hmm, but Unix does not really distuingish between serial ports and ttys. So what precisely is the difference in behaviour when I have opened a /dev/hvcXX and a /dev/vportXXX? What happens if start a getty on /dev/vportXXX? And why couldn't I use /dev/hvcXXX for fast data transfer, too? Or is the only difference on the host side? i.e. the destinction between access via pty and access via sockets? Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
rawhide report: 20110706 changes
Compose started at Wed Jul 6 08:15:05 UTC 2011 Broken deps for x86_64 -- acheck-0.5.1-4.fc15.noarch requires perl(Text::Aspell) almanah-0.7.3-12.fc16.x86_64 requires libedataserverui-3.0.so.0()(64bit) almanah-0.7.3-12.fc16.x86_64 requires libcamel-1.2.so.26()(64bit) 1:anerley-0.2.14-7.fc16.i686 requires libcamel-1.2.so.26 1:anerley-0.2.14-7.fc16.x86_64 requires libcamel-1.2.so.26()(64bit) audacious-plugin-xmp-3.3.0-7.fc16.x86_64 requires audacious(plugin-api) = 0:19 bibletime-2.8.1-1.fc16.x86_64 requires libclucene.so.0()(64bit) camcardsync-0.1.1-4.fc15.x86_64 requires libhal.so.1()(64bit) contacts-0.12-7.fc16.x86_64 requires libcamel-1.2.so.26()(64bit) deskbar-applet-2.32.0-4.fc15.x86_64 requires gnome-python2-applet deskbar-applet-2.32.0-4.fc15.x86_64 requires libebook-1.2.so.10()(64bit) deskbar-applet-2.32.0-4.fc15.x86_64 requires libcamel-1.2.so.23()(64bit) dh-make-0.55-3.fc15.noarch requires debhelper ekiga-3.3.0-10.fc16.x86_64 requires libcamel-1.2.so.26()(64bit) evolution-couchdb-0.5.90-2.fc16.x86_64 requires libcamel-provider-1.2.so.26()(64bit) evolution-couchdb-0.5.90-2.fc16.x86_64 requires libcamel-1.2.so.26()(64bit) evolution-exchange-3.1.2-1.fc16.x86_64 requires libcamel-1.2.so.26()(64bit) evolution-exchange-3.1.2-1.fc16.x86_64 requires libedataserverui-3.0.so.0()(64bit) evolution-exchange-3.1.2-1.fc16.x86_64 requires libcamel-provider-1.2.so.26()(64bit) evolution-mapi-3.1.2-1.fc16.i686 requires libcamel-provider-1.2.so.26 evolution-mapi-3.1.2-1.fc16.i686 requires libcamel-1.2.so.26 evolution-mapi-3.1.2-1.fc16.x86_64 requires libcamel-provider-1.2.so.26()(64bit) evolution-mapi-3.1.2-1.fc16.x86_64 requires libcamel-1.2.so.26()(64bit) evolution-rss-0.2.90-21.20110523git.fc16.x86_64 requires libebook-1.2.so.10()(64bit) evolution-rss-0.2.90-21.20110523git.fc16.x86_64 requires libedataserverui-3.0.so.0()(64bit) evolution-rss-0.2.90-21.20110523git.fc16.x86_64 requires libcamel-provider-1.2.so.25()(64bit) evolution-rss-0.2.90-21.20110523git.fc16.x86_64 requires libcamel-1.2.so.25()(64bit) evolution-rss-0.2.90-21.20110523git.fc16.x86_64 requires libgnome-desktop-3.so.0()(64bit) evolution-sharp-0.21.1-14.fc16.x86_64 requires libcamel-1.2.so.26()(64bit) exaile-0.3.2.1-1.fc16.noarch requires hal fawkes-guis-0.4.2-4.fc16.i686 requires libgraph.so.4 fawkes-guis-0.4.2-4.fc16.i686 requires libcdt.so.4 fawkes-guis-0.4.2-4.fc16.i686 requires libgvc.so.5 fawkes-guis-0.4.2-4.fc16.x86_64 requires libgraph.so.4()(64bit) fawkes-guis-0.4.2-4.fc16.x86_64 requires libcdt.so.4()(64bit) fawkes-guis-0.4.2-4.fc16.x86_64 requires libgvc.so.5()(64bit) fawkes-plugin-player-0.4.2-4.fc16.x86_64 requires libgeos-3.2.1.so()(64bit) file-browser-applet-0.6.6-1.fc15.x86_64 requires libpanel-applet-2.so.0()(64bit) fldigi-3.21.7-1.fc16.x86_64 requires libfltk_images.so.1.1()(64bit) fldigi-3.21.7-1.fc16.x86_64 requires libfltk.so.1.1()(64bit) gdb-heap-0.5-5.fc16.x86_64 requires glibc(x86-64) = 0:2.13.90 gedit-valencia-0.3.0-4.fc14.x86_64 requires libvala-0.10.so.0()(64bit) ghc-hinotify-0.3.1-9.fc16.i686 requires libHSarray-0.3.0.2-ghc7.0.2.so ghc-hinotify-0.3.1-9.fc16.i686 requires libHSdirectory-1.1.0.0-ghc7.0.2.so ghc-hinotify-0.3.1-9.fc16.i686 requires libHSghc-prim-0.2.0.0-ghc7.0.2.so ghc-hinotify-0.3.1-9.fc16.i686 requires libHSold-time-1.0.0.6-ghc7.0.2.so ghc-hinotify-0.3.1-9.fc16.i686 requires libHSold-locale-1.0.0.2-ghc7.0.2.so ghc-hinotify-0.3.1-9.fc16.i686 requires libHSunix-2.4.2.0-ghc7.0.2.so ghc-hinotify-0.3.1-9.fc16.i686 requires libHSfilepath-1.2.0.0-ghc7.0.2.so ghc-hinotify-0.3.1-9.fc16.i686 requires libHSbase-4.3.1.0-ghc7.0.2.so ghc-hinotify-0.3.1-9.fc16.i686 requires libHSinteger-gmp-0.2.0.3-ghc7.0.2.so ghc-hinotify-0.3.1-9.fc16.i686 requires libHScontainers-0.4.0.0-ghc7.0.2.so ghc-hinotify-0.3.1-9.fc16.x86_64 requires libHSghc-prim-0.2.0.0-ghc7.0.2.so()(64bit) ghc-hinotify-0.3.1-9.fc16.x86_64 requires libHSold-time-1.0.0.6-ghc7.0.2.so()(64bit) ghc-hinotify-0.3.1-9.fc16.x86_64 requires libHSbase-4.3.1.0-ghc7.0.2.so()(64bit) ghc-hinotify-0.3.1-9.fc16.x86_64 requires libHSinteger-gmp-0.2.0.3-ghc7.0.2.so()(64bit) ghc-hinotify-0.3.1-9.fc16.x86_64 requires libHSold-locale-1.0.0.2-ghc7.0.2.so()(64bit) ghc-hinotify-0.3.1-9.fc16.x86_64 requires libHSfilepath-1.2.0.0-ghc7.0.2.so()(64bit) ghc-hinotify-0.3.1-9.fc16.x86_64 requires ghc(base-4.3.1.0) = 0:c33a1741503ded8a0170884e8a2e4fa2 ghc-hinotify-0.3.1-9.fc16.x86_64 requires libHScontainers-0.4.0.0-ghc7.0.2.so()(64bit)
Re: systemd: Tagging /dev/virtio-ports/* for systemd
On Wed, 06.07.11 12:28, Richard W.M. Jones (rjo...@redhat.com) wrote: I haven't tested this yet .. will do later today. But comments welcome on: http://pkgs.fedoraproject.org/gitweb/?p=libguestfs.git;a=blob;f=99-guestfsd.rules;h=ab4f6800bbd847307aceb2cb52e984524eaee52c;hb=HEAD http://pkgs.fedoraproject.org/gitweb/?p=libguestfs.git;a=blob;f=guestfsd.service;h=482d1e2bf1fb1c791e3adfe3f58716c38edb6b3d;hb=HEAD You can drop the [Install] line, too. http://pkgs.fedoraproject.org/gitweb/?p=libguestfs.git;a=blob;f=libguestfs.spec;h=c78a5f75349fd34944c7a5eb637050ed6bf65c1e;hb=HEAD#l330 http://pkgs.fedoraproject.org/gitweb/?p=libguestfs.git;a=blob;f=libguestfs.spec;h=c78a5f75349fd34944c7a5eb637050ed6bf65c1e;hb=HEAD#l652 http://pkgs.fedoraproject.org/gitweb/?p=libguestfs.git;a=blob;f=libguestfs.spec;h=c78a5f75349fd34944c7a5eb637050ed6bf65c1e;hb=HEAD#l755 Looks good! Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd: Tagging /dev/virtio-ports/* for systemd
On Wed, 06.07.11 12:21, Richard W.M. Jones (rjo...@redhat.com) wrote: On Tue, Jul 05, 2011 at 08:36:42PM +0200, Lennart Poettering wrote: On Tue, 05.07.11 16:54, Daniel P. Berrange (berra...@redhat.com) wrote: [Service] ExecStart=-/usr/sbin/guestfsd Prefixing the binary path with - will result in the exit code of guestfsd be ignored, i.e. we wouldn't put the service into failed state if it crashes (or exits otherwise abnormally). I'd encourage never to prefix with - unless you have a really good reason to. In this case, I think we do. The daemon only handles one connection at a time (that is the nature of virtio-serial ports) and it will exit with EXIT_FAILURE if an error is read in the protocol. This can happen in some legitimate-ish cases, eg. if the host side disconnects without properly closing the connection. Wouldn't it make sense to fix the daemon to return EXIT_SUCCESS in those legitimate-ish cases? But what we'd want to avoid is the case where the daemon dies during startup, and we get into a loop repeatedly relaunching the daemon. systemd does not distuingish between failure-on-start and failure-during-runtime. The question is, does systemd implement respawn throttling like inetd? Yes, we rate limit almost everything. There's even a patch floating around on our mailing list right now which we will probably merge pretty soon which allows you to configure in a service how often we should retry respawning the service before giving up, if it fails. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: cups service gone walkabouts?
On 06/07/11 13:27, Tim Waugh wrote: On Wed, 2011-07-06 at 11:32 +, Jóhann B. Guðmundsson wrote: I thought with Lennart patch/setup on his blog the only case you need to enable cups is if you are going to be running centralized printer server which in that case the admin himself would enabled it hence we would not have to have it enabled by default... Yes, you're quite right, my mistake. Except that the cups package only seems to have the service unit and not the socket or path units so socket activation won't work at the moment. I had assumed that was deliberate, but maybe not? Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: cups service gone walkabouts?
On Wed, 2011-07-06 at 13:38 +0100, Tom Hughes wrote: I had assumed that was deliberate, but maybe not? Try today's rawhide. Tim. */ 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: systemd: Tagging /dev/virtio-ports/* for systemd
On Wed, Jul 06, 2011 at 02:27:58PM +0200, Lennart Poettering wrote: On Wed, 06.07.11 10:22, Daniel P. Berrange (berra...@redhat.com) wrote: So, I am a bit confused now after reading this: http://fedoraproject.org/wiki/Features/VirtioSerial How does /dev/hvcxxx relate to these virtio ports? hvc ports are tagged systemd anyway in udev, so if this is the same thing, why do we have to tag the virtio ports too? Can you explain how hvc and virtio relate to each other and under which kernel device names they show up in udev and how they correspond? In QEMU, there is one PCI device virtio-serial-pci. In QEMU's view this device is a bus to which we then attach zero or more 'virtconsole' or 'virtserialport' devices. The 'virtconsole' device is a paravirt text console, which appears as /dev/hvcNNN in the guest. These are intended for interactive login and would be expected to run a mingetty/agetty process. Hmm, but Unix does not really distuingish between serial ports and ttys. So what precisely is the difference in behaviour when I have opened a /dev/hvcXX and a /dev/vportXXX? What happens if start a getty on /dev/vportXXX? And why couldn't I use /dev/hvcXXX for fast data transfer, too? There's not really any functional difference between them once open. The difference is is really about providing hints to the guest OS as to how to configure the devices out of the box The goal for the virtconsole devices was that a guest OS can just automatically start a getty on every /dev/hvcXXX device it finds. So a host admin can just add console devices to a guest config and get a login without any extra guest OS configuration work. The virtserial devices meanwhile have a admin defined name associated with them to (in my example 'org.libguestfs.channel.0') so guest OS agents can have a predictable way to identify which ports have been exposed from the host for their use. eg, consider if two guest agents 'guestfsd' and 'matahari' both wanted to run in a guest and we were using just /dev/hvcXXX devices. There'd be no way for them to decide which of /dev/hvc0, /dev/hvc1 applied was theirs. With virtserial devices having a stable name, they can see which is which device immediately. Or is the only difference on the host side? i.e. the destinction between access via pty and access via sockets? No, that was just two example configs - the range of host side config options is the same for both, with exception that virtserial devices have an additional 'name' associated with them which maps to the device /dev/virtio-ports/$NAME in Linux guests. 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 :| -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
ushare FTBFS on EL-6
Hi, I would like to have ushare running on my EL-6 home server and there is no build for EPEL-6. So I have build libupnp (no problems there, I've pushed it to -testing), and when trying to build ushare I've got the problem as seen in the log on http://mcepl.fedorapeople.org/tmp/ushare-rpmbuild-log.txt. Does anybody have any idea, what's wrong with my attempt? Thanks a lot, Matěj -- http://www.ceplovi.cz/matej/, Jabber: mceplatceplovi.cz GPG Finger: 89EF 4BC6 288A BF43 1BAB 25C3 E09F EF25 D964 84AC Finally, brethren, whatsoever things are true, whatsoever things are honest, whatsoever things are just, whatsoever things are pure, whatsoever things are lovely, whatsoever things are of good report; if there be any virtue, and if there be any praise, think on these things. -- Philipians 4:8 KJV smime.p7s Description: S/MIME Cryptographic Signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: cups service gone walkabouts?
Am 06.07.2011 11:19, schrieb Paul F. Johnson: Hi, It seems that after yesterdays (5th July) mammoth rawhide update, that the cups daemon has vanished from /etc/init.d - any idea if this is just an oversight? sounds like the switch to systemd started good! signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd: Tagging /dev/virtio-ports/* for systemd
On Wed, Jul 06, 2011 at 02:35:13PM +0200, Lennart Poettering wrote:
Wouldn't it make sense to fix the daemon to return EXIT_SUCCESS in those
legitimate-ish cases?
It's probably just me but I find code that does this slightly
repugnant:
if (some_syscall() == -1) {
perror (some_syscall);
exit (EXIT_SUCCESS);
}
There are a large number of places in the code which we would need to
examine and possibly change.
I think as long as systemd is doing rate-limiting, we should be fine.
The daemon is heavily tested anyway and hasn't so far failed at
start-up time ...
Anyway, I'm going to test it.
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
virt-top is 'top' for virtual machines. Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://et.redhat.com/~rjones/virt-top
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: ushare FTBFS on EL-6
On 07/06/2011 02:49 PM, Matěj Cepl wrote: I would like to have ushare running on my EL-6 home server and there is no build for EPEL-6. So I have build libupnp (no problems there, I've pushed it to -testing), and when trying to build ushare I've got the problem as seen in the log on http://mcepl.fedorapeople.org/tmp/ushare-rpmbuild-log.txt. Does anybody have any idea, what's wrong with my attempt? according to * http://forum.buffalo.nas-central.org/viewtopic.php?f=39t=14986 and * https://dev.openwrt.org/ticket/8296 it's your version of libupnp, which has a newer api than the one your version of ushare expects. There is a patch attached to the openwrt ticket which fixes ushare compilation against newer libupnp libs. Christoph. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: ushare FTBFS on EL-6
On Wed, Jul 06, 2011 at 02:49:50PM +0200, Matěj Cepl wrote: I would like to have ushare running on my EL-6 home server and there is no build for EPEL-6. So I have build libupnp (no problems there, I've pushed it to -testing), and when trying to build ushare I've got the problem as seen in the log on http://mcepl.fedorapeople.org/tmp/ushare-rpmbuild-log.txt. Does anybody have any idea, what's wrong with my attempt? Most obviously, the code needs to #include stdio.h and #include string.h in a lot more files. The actual bug is on this line: struct UpnpVirtualDirCallbacks virtual_dir_callbacks; This struct appears to exist and the header is included correctly. Is the version of upnp that you are using older than 1.6.6? Does it have this struct defined in the header file upnp/upnp.h? BTW looking at the upstream Mercurial repo, the code has changed quite a bit since 1.1a (from 2007). The header problems above are seemingly fixed. Perhaps try the latest version from Mercurial? 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#) http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: ushare FTBFS on EL-6
On Wed, 2011-07-06 at 15:40 +0200, Christoph Trassl wrote: On 07/06/2011 02:49 PM, Matěj Cepl wrote: I would like to have ushare running on my EL-6 home server and there is no build for EPEL-6. So I have build libupnp (no problems there, I've pushed it to -testing), and when trying to build ushare I've got the problem as seen in the log on http://mcepl.fedorapeople.org/tmp/ushare-rpmbuild-log.txt. Does anybody have any idea, what's wrong with my attempt? according to * http://forum.buffalo.nas-central.org/viewtopic.php?f=39t=14986 and * https://dev.openwrt.org/ticket/8296 it's your version of libupnp, which has a newer api than the one your version of ushare expects. There is a patch attached to the openwrt ticket which fixes ushare compilation against newer libupnp libs. Thanks for finding this patch! I've added it to the ushare package. - 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: vsftpd in the news
On 07/06/2011 03:19 AM, Michael Schwendt wrote: If we include the whole show in the src.rpm, how does that add any safety? It doesn't make the system bulletproof, but it makes it a little harder to break, and, perhaps more importantly, adds accountability, i.e. helps to figure out at which point the source was corrupted. Remember the original Linux kernel trojan: it was discovered because the bitkeeper checksums showed an unaccounted-for chunk. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: cups service gone walkabouts?
On 07/06/2011 09:21 AM, Reindl Harald wrote: Am 06.07.2011 11:19, schrieb Paul F. Johnson: Hi, It seems that after yesterdays (5th July) mammoth rawhide update, that the cups daemon has vanished from /etc/init.d - any idea if this is just an oversight? sounds like the switch to systemd started good! The development cycle is exactly to catch any potential issues like this and the sooner we have those native service files out there the better. So I propose that instead of you complaining here on the list you help out in the migration progress and start converting legacy sysv init scripts to a native systemd service files. If you are uncapable of doing that I suggest that you keep these sarcastic remarks of yours to yourself and off list. Thanks JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Orphaning packages
I no longer have a need/care for these packages, they are up for grabs: contacts inotail -- 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: Orphaning packages
On Wed, Jul 06, 2011 at 11:23:06AM -0700, Jesse Keating wrote: I no longer have a need/care for these packages, they are up for grabs: contacts inotail I'll take inotail. --CJD -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: enlightenment project seeks package maintainer!
Hi, I would like to take ownership of the enlightenment package. But I am not a packager yet, still waiting for a sponsor. Please see my review request for pyxfce ... In Bugzilla, there seems not to be any review request entry from the past about the enlightenment package that has stopped to be maintained since Fedora 14 and upwards. Does anybody know more? I've done some testing with ArchLinux and their official e17-svn package. The desktop looks really awesome and I see an opportunity to have an E17 spin of Fedora in the far future, maybe. Greetings, Raphael Hi, I am a developer with the enlightenment project (http://enlightenment.org). We have just recently released the 1.0 version of our libraries, known as the EFL, and are now attempting to find people on various distros to help spread the word. Currently, we have packagers working on Arch, Debian, Gentoo, Ubuntu (debian), and a number of others, and we would like to add Fedora to this list! Within our community, we have people who work on .spec files already, and such files already exist for all the libraries that we would like to see in Fedora. The spec files are in the toplevel directory of each project, and I will link them here for easy viewing: https://svn.enlightenment.org/svn/e/tags/ecore-1.0.0/ecore.spec.in https://svn.enlightenment.org/svn/e/tags/e_dbus-1.0.0/e_dbus.spec.in https://svn.enlightenment.org/svn/e/tags/edje-1.0.0/edje.spec.in https://svn.enlightenment.org/svn/e/tags/eet-1.4.0/eet.spec.in https://svn.enlightenment.org/svn/e/tags/eeze-1.0.1/eeze.spec.in https://svn.enlightenment.org/svn/e/tags/efreet-1.0.0/efreet.spec.in https://svn.enlightenment.org/svn/e/tags/eina-1.0.0/eina.spec.in https://svn.enlightenment.org/svn/e/tags/embryo-1.0.0/embryo.spec.in https://svn.enlightenment.org/svn/e/tags/evas-1.0.0/evas.spec.in There is one minor cleanup that must be made on our end in the ecore spec to use c-ares, but other than that they should work fine. Obviously they may not meet your QA regulations, so changes will be made where necessary. Note that this is NOT E17. These are only the underlying libraries which have been in development for the last 10 years and have recently reached 1.0. I am hopeful that this mail will interest some of the developers on the list :) You can either reply directly to this email or come to #edevelop on Freenode to talk to us in realtime. Thanks! -- Mike Blumenkrantz Zentific: NULL pointer dereferences now 50% off! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: cups service gone walkabouts?
On Wed, 2011-07-06 at 15:00 +, Jóhann B. Guðmundsson wrote: On 07/06/2011 09:21 AM, Reindl Harald wrote: Am 06.07.2011 11:19, schrieb Paul F. Johnson: Hi, It seems that after yesterdays (5th July) mammoth rawhide update, that the cups daemon has vanished from /etc/init.d - any idea if this is just an oversight? sounds like the switch to systemd started good! The development cycle is exactly to catch any potential issues like this and the sooner we have those native service files out there the better. So I propose that instead of you complaining here on the list you help out in the migration progress and start converting legacy sysv init scripts to a native systemd service files. If you are uncapable of doing that I suggest that you keep these sarcastic remarks of yours to yourself and off list. erm, I didn't read the initial post as at all sarcastic. I think you're over-interpreting. Reindl simply suggested why the SysV definition had disappeared - sounds like the switch to systemd started - and gave an opinion - good!. I can't see any reason to interpret the opinion as sarcasm. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Any progress on this critical audio bug?
https://bugzilla.redhat.com/show_bug.cgi?id=704816 This bug is pretty critical for all people with this audio chip, and it needs some love because there is no comment in over two months. Cheers, Valent. -- follow me - www.twitter.com/valentt http://kernelreloaded.blog385.com linux, anime, spirituality, wireless, scuba, linuxmce smart home, zwave ICQ: 2125241, Skype: valent.turkovic, MSN: valent.turko...@hotmail.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: OpenMPI, Emacs and libotf problems
On Wed, 2011-07-06 at 20:03 +1000, Amit Saha wrote: Hello all: I am hoping it is OK to discuss this here. I came across this problem when I was building a custom spin where the kickstart file installs 'openmpi' before 'emacs'. When I start emacs, here is what I get: $emacs emacs: error while loading shared libraries: libotf.so.0: cannot open shared object file: No such file or directory So, this library is missing. However, this should have been installed as its a dependency, right? It can be seen that there are two providers listed for libotf.so.0. Since 'openmpi' was already installed, so it didn't bother installing 'libotf'. I could simulate the scenario on a Fedora 15 installation: The problem is that openmpi includes a libotf.so.0, but it's not in a path that the system will usually look in for shared libraries, it's in (libdir)/openmpi/lib/ . openmpi probably shouldn't have a private copy of libotf in the first place (assuming that's what it is, and not just a naming coincidence), but if it's going to have one, it should have a line in the spec to prevent RPM auto-provides from giving the openmpi package a Provides for libotf.so.0. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Any progress on this critical audio bug?
On Wed, 2011-07-06 at 21:34 +0200, valent.turko...@gmail.com wrote: https://bugzilla.redhat.com/show_bug.cgi?id=704816 This bug is pretty critical for all people with this audio chip, and it needs some love because there is no comment in over two months. You're slightly more likely to get a response by mailing the ALSA project list, or filing a bug at ALSA. Check the archives first as it may well already have been discussed. On the ALSA lists there's maybe five or six people who might, possibly, care. On Fedora Bugzilla there's about one: half a Lennart and half a Jaroslav. It doesn't give you much of a chance. As Lennart never fails to point out, audio on Linux is in generally horribly under-resourced. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: OpenMPI, Emacs and libotf problems
On Wed, 2011-07-06 at 22:46 +0300, Jussi Lehtola wrote: On Wed, 06 Jul 2011 12:39:14 -0700 Adam Williamson awill...@redhat.com wrote: On Wed, 2011-07-06 at 20:03 +1000, Amit Saha wrote: So, this library is missing. However, this should have been installed as its a dependency, right? It can be seen that there are two providers listed for libotf.so.0. Since 'openmpi' was already installed, so it didn't bother installing 'libotf'. I could simulate the scenario on a Fedora 15 installation: The problem is that openmpi includes a libotf.so.0, but it's not in a path that the system will usually look in for shared libraries, it's in (libdir)/openmpi/lib/ . openmpi probably shouldn't have a private copy of libotf in the first place (assuming that's what it is, and not just a naming coincidence), but if it's going to have one, it should have a line in the spec to prevent RPM auto-provides from giving the openmpi package a Provides for libotf.so.0. It's certainly not the same libotf, since OpenMPI does not have *anything* to do with truetype fonts. Even though the library is installed in a non-system directory, applications that link against libotf will get an automatically generated Requires: against it anyways. Well, packages get an auto-generated Requires: for libotf.so.0. Anything that claims to provide libotf.so.0 will satisfy this. The most correct solution is simply for openmpi to stop claiming to provide libotf.so.0 because, for practical purposes, it does not provide it: even if the library in question were the same one, openmpi's copy is not in a location that other packages will know how to use, so in practical terms, it does not provide the library. Maybe OpenMPI upstream should be contacted and asked to rename their libotf. This would also indeed make sense. Googling 'openmpi libotf' I see that at least Gentoo and Debian have come across this before. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: OpenMPI, Emacs and libotf problems
On Wed, 06 Jul 2011 12:54:48 -0700 Adam Williamson awill...@redhat.com wrote: It's certainly not the same libotf, since OpenMPI does not have *anything* to do with truetype fonts. Even though the library is installed in a non-system directory, applications that link against libotf will get an automatically generated Requires: against it anyways. Well, packages get an auto-generated Requires: for libotf.so.0. Anything that claims to provide libotf.so.0 will satisfy this. The most correct solution is simply for openmpi to stop claiming to provide libotf.so.0 because, for practical purposes, it does not provide it: even if the library in question were the same one, openmpi's copy is not in a location that other packages will know how to use, so in practical terms, it does not provide the library. .. but on the other hand, the same logic applies in the opposite sense: if something requires OpenMPI's libotf.so.0, also the truetype libotf will satisfy the requirement. (Although openmpi apps typically link to a half a dozen other openmpi libs as well). -- Jussi Lehtola Fedora Project Contributor jussileht...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: OpenMPI, Emacs and libotf problems
On Wed, 2011-07-06 at 23:02 +0300, Jussi Lehtola wrote: On Wed, 06 Jul 2011 12:54:48 -0700 Adam Williamson awill...@redhat.com wrote: It's certainly not the same libotf, since OpenMPI does not have *anything* to do with truetype fonts. Even though the library is installed in a non-system directory, applications that link against libotf will get an automatically generated Requires: against it anyways. Well, packages get an auto-generated Requires: for libotf.so.0. Anything that claims to provide libotf.so.0 will satisfy this. The most correct solution is simply for openmpi to stop claiming to provide libotf.so.0 because, for practical purposes, it does not provide it: even if the library in question were the same one, openmpi's copy is not in a location that other packages will know how to use, so in practical terms, it does not provide the library. .. but on the other hand, the same logic applies in the opposite sense: if something requires OpenMPI's libotf.so.0, also the truetype libotf will satisfy the requirement. (Although openmpi apps typically link to a half a dozen other openmpi libs as well). Nothing really could require OpenMPI's libotf as things stand, because of what I wrote above: nothing can find it unless it uses a custom linker path. If OpenMPI actually wanted the library to be something other packages can use, it should really install it in a shared path (and, as we've already discussed, rename it). If we're just talking about different OpenMPI packages, they can handle the intra-dependencies manually, I'd say. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: OpenMPI, Emacs and libotf problems
Adam Williamson wrote on Wed, Jul 06, 2011 at 12:54:48PM -0700: On Wed, 2011-07-06 at 22:46 +0300, Jussi Lehtola wrote: On Wed, 06 Jul 2011 12:39:14 -0700 Adam Williamson awill...@redhat.com wrote: On Wed, 2011-07-06 at 20:03 +1000, Amit Saha wrote: So, this library is missing. However, this should have been installed as its a dependency, right? It can be seen that there are two providers listed for libotf.so.0. Since 'openmpi' was already installed, so it didn't bother installing 'libotf'. I could simulate the scenario on a Fedora 15 installation: The problem is that openmpi includes a libotf.so.0, but it's not in a path that the system will usually look in for shared libraries, it's in (libdir)/openmpi/lib/ . openmpi probably shouldn't have a private copy of libotf in the first place (assuming that's what it is, and not just a naming coincidence), but if it's going to have one, it should have a line in the spec to prevent RPM auto-provides from giving the openmpi package a Provides for libotf.so.0. It's certainly not the same libotf, since OpenMPI does not have *anything* to do with truetype fonts. Even though the library is installed in a non-system directory, applications that link against libotf will get an automatically generated Requires: against it anyways. Well, packages get an auto-generated Requires: for libotf.so.0. Anything that claims to provide libotf.so.0 will satisfy this. The most correct solution is simply for openmpi to stop claiming to provide libotf.so.0 because, for practical purposes, it does not provide it: even if the library in question were the same one, openmpi's copy is not in a location that other packages will know how to use, so in practical terms, it does not provide the library. If I run into this kind of a situation (a false auto-generated Provides), is it possible to disable just that one entry, or do I have to disable AutoProv entirely and keep track of the libs myself? Thanks, -matyas -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: OpenMPI, Emacs and libotf problems
On Wed, 2011-07-06 at 15:24 -0500, Mátyás Selmeci wrote: Well, packages get an auto-generated Requires: for libotf.so.0. Anything that claims to provide libotf.so.0 will satisfy this. The most correct solution is simply for openmpi to stop claiming to provide libotf.so.0 because, for practical purposes, it does not provide it: even if the library in question were the same one, openmpi's copy is not in a location that other packages will know how to use, so in practical terms, it does not provide the library. If I run into this kind of a situation (a false auto-generated Provides), is it possible to disable just that one entry, or do I have to disable AutoProv entirely and keep track of the libs myself? http://fedoraproject.org/wiki/AutoReqProv_%28draft% 29#Removing_items_from_the_provides_stream_.28post-scan_filtering.29 -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: OpenMPI, Emacs and libotf problems
On Wed, Jul 6, 2011 at 2:26 PM, Adam Williamson awill...@redhat.com wrote: http://fedoraproject.org/wiki/AutoReqProv_%28draft%29#Removing_items_from_the_provides_stream_.28post-scan_filtering.29 Or rather https://fedoraproject.org/wiki/Packaging:AutoProvidesAndRequiresFiltering, and I can't use that in a couple of similar cases due to the restrictions in the Usage section. -- Jerry James http://www.jamezone.org/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: OpenMPI, Emacs and libotf problems
On Wed, 06 Jul 2011 13:09:41 -0700 Adam Williamson awill...@redhat.com wrote: .. but on the other hand, the same logic applies in the opposite sense: if something requires OpenMPI's libotf.so.0, also the truetype libotf will satisfy the requirement. (Although openmpi apps typically link to a half a dozen other openmpi libs as well). Nothing really could require OpenMPI's libotf as things stand, because of what I wrote above: nothing can find it unless it uses a custom linker path. If OpenMPI actually wanted the library to be something other packages can use, it should really install it in a shared path (and, as we've already discussed, rename it). If we're just talking about different OpenMPI packages, they can handle the intra-dependencies manually, I'd say. Not really, since when the MPI environment is loaded the relevant library paths are added to LD_LIBRARY_PATH. They're not installed in system locations, since e.g. all MPI libraries ship with libmpi.so, and there are many variants: OpenMPI, MPICH2, MVAPICH, and so on. -- Jussi Lehtola Fedora Project Contributor jussileht...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Bug 719048] perl-HTTP-Server-Simple has no dependencies on perl-CGI
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=719048 Fedora Update System upda...@fedoraproject.org changed: What|Removed |Added Status|MODIFIED|ON_QA --- Comment #4 from Fedora Update System upda...@fedoraproject.org 2011-07-06 17:24:38 EDT --- Package perl-HTTP-Server-Simple-0.44-1.fc15: * should fix your issue, * was pushed to the Fedora 15 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing perl-HTTP-Server-Simple-0.44-1.fc15' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/perl-HTTP-Server-Simple-0.44-1.fc15 then log in and leave karma (feedback). -- 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
LXC package ownership
Hello all, At some point in the timeline it would appear that lxc got orphaned. This was brought up today in #fedora-devel and I'm announcing my intent to take ownership and hoping others might be interested in helping play along with co-maintainership. thm already expressed interest in co-maintaining with me but as always, collaboration is welcome and more hands/heads/minds/ideas/etc would be a happy addition! :) There are apparently some issues currently in Fedora 15 that we hope to iron out in the not to distant future. -AdamM -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: OpenMPI, Emacs and libotf problems
On Wed, Jul 6, 2011 at 3:28 PM, Ville Skyttä ville.sky...@iki.fi wrote: For rpm = 4.9, there's __provides_exclude and __provides_exclude_from which I believe don't have those problems. http://rpm.org/wiki/PackagerDocs/DependencyGenerator#TweakingDependencyGenerators Oh, excellent! Thanks, Ville. That's F15+, I believe. Off to fix some packages -- Jerry James http://www.jamezone.org/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: pyxfce package
On Wed, 2011-07-06 at 21:16 +0200, Raphael Groner wrote: FYI, since nobody seems to show any interest at Xfce upstream http://lists.fedoraproject.org/pipermail/xfce/2011-July/000630.html I don't think it should be in Fedora then. We should focus on well maintained software. Regards, Christoph -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Unorphaning packages
Hi, I'm taking the following packages into maintainership: scrot stfl (dependency of newsbeuter) googlecl (if chkr wants maintainership, that's fine, I'll wait until Friday to take it) renameutils Comaintainers welcome. --Ben -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Orphaning packages
On Thu, Jul 7, 2011 at 4:23 AM, Jesse Keating jkeat...@redhat.com wrote: I no longer have a need/care for these packages, they are up for grabs: contacts inotail I haven't maintained a package before, but I am looking for a starting point and I would like to take up contacts. -Amit -- http://echorand.me -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Bug 719278] New: perl-App-SVN-Bisect-1.1 is available
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. Summary: perl-App-SVN-Bisect-1.1 is available https://bugzilla.redhat.com/show_bug.cgi?id=719278 Summary: perl-App-SVN-Bisect-1.1 is available Product: Fedora Version: rawhide Platform: Unspecified OS/Version: Unspecified Status: NEW Keywords: FutureFeature, Triaged Severity: unspecified Priority: unspecified Component: perl-App-SVN-Bisect AssignedTo: xav...@bachelot.org ReportedBy: upstream-release-monitor...@fedoraproject.org QAContact: extras...@fedoraproject.org CC: xav...@bachelot.org, fedora-perl-devel-l...@redhat.com Classification: Fedora Story Points: --- Latest upstream release: 1.1 Current version in Fedora Rawhide: 1.0 URL: http://search.cpan.org/dist/App-SVN-Bisect/ 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 -- 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-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 715559] perl-Mojolicious-1.56 is available
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=715559 Upstream Release Monitoring upstream-release-monitor...@fedoraproject.org changed: What|Removed |Added Summary|perl-Mojolicious-1.55 is|perl-Mojolicious-1.56 is |available |available --- Comment #3 from Upstream Release Monitoring upstream-release-monitor...@fedoraproject.org 2011-07-06 06:36:56 EDT --- Latest upstream release: 1.56 Current version in Fedora Rawhide: 1.46 URL: http://search.cpan.org/dist/Mojolicious/ 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 -- 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-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 719281] New: perl-XML-Writer-0.612 is available
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. Summary: perl-XML-Writer-0.612 is available https://bugzilla.redhat.com/show_bug.cgi?id=719281 Summary: perl-XML-Writer-0.612 is available Product: Fedora Version: rawhide Platform: Unspecified OS/Version: Unspecified Status: NEW Keywords: FutureFeature, Triaged Severity: unspecified Priority: unspecified Component: perl-XML-Writer AssignedTo: al...@users.sourceforge.net ReportedBy: upstream-release-monitor...@fedoraproject.org QAContact: extras...@fedoraproject.org CC: al...@users.sourceforge.net, fedora-perl-devel-l...@redhat.com Classification: Fedora Story Points: --- Latest upstream release: 0.612 Current version in Fedora Rawhide: 0.606 URL: http://search.cpan.org/dist/XML-Writer/ 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 -- 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-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 719280] New: perl-Time-modules-2011.0517 is available
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. Summary: perl-Time-modules-2011.0517 is available https://bugzilla.redhat.com/show_bug.cgi?id=719280 Summary: perl-Time-modules-2011.0517 is available Product: Fedora Version: rawhide Platform: Unspecified OS/Version: Unspecified Status: NEW Keywords: FutureFeature, Triaged Severity: unspecified Priority: unspecified Component: perl-Time-modules AssignedTo: extras-orp...@fedoraproject.org ReportedBy: upstream-release-monitor...@fedoraproject.org QAContact: extras...@fedoraproject.org CC: xav...@bachelot.org, extras-orp...@fedoraproject.org, fedora-perl-devel-l...@redhat.com Classification: Fedora Story Points: --- Latest upstream release: 2011.0517 Current version in Fedora Rawhide: 2006.0814 URL: http://search.cpan.org/dist/Time-modules/ 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 -- 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-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 719278] perl-App-SVN-Bisect-1.1 is available
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=719278 Xavier Bachelot xav...@bachelot.org changed: What|Removed |Added Status|NEW |CLOSED Resolution||RAWHIDE Last Closed||2011-07-06 07:58:36 -- 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-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
