Possible CAcert Assurance Event during FUDCon
I'm a CAcert assurer, and was wanting to check to see if there are any CAcert assurers who will be attending FUDCon and would be interested in offering CAcert assurances at some point during FUDCon. If you are, please email me. I'd like to get a group of assurers together at some point during the event. This will be especially important because CAcert is getting ready to revoke the points that people obtained via the former Thawte Points Transfer system, so some people will be losing their assurer status (or 50 point status that lets you get your name in your certificates). We are also planning a GPG/PGP key signing party, more details of that will come soon. You can contact me at either n...@fedoraproject.org or n...@cacert.org Thanks, Nick -- Nick Bebout n...@cacert.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: (re)introducing - fedora-review - tool to help with package reviews
On 12/15/2011 09:57 PM, Brendan Jones wrote: On 11/21/2011 02:14 PM, Stanislav Ochotnicky wrote: Hello fellow devs, I am sure quite a few of you have done some reviews and thought "Hey, a,b,c and d could be automated. For E I could use some more information that can be automatically gathered". Some of you even wrote your own tools to do some of these things. Hi Stan, great idea. Will try to use this prior to any forthcoming reviews. I find the most time consuming task in the review process is the license check. I use a combination of find/head/grep commands to try and determine if some of the source files have differing licenses to the stated one in the spec. None of my methods guarantee 100% license detection, given the sheer number of licenses out there, although if we could consolidate all of the methods reviewers use for this we would have a nifty tool indeed. Not sure if this is something which should be part of this package or another entirely? regards, Brendan The guys on the packaging list enlightened me on the existence of licensecheck from rpmdevtools. From my brief tests it does a good job but have not used it against cornercases -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
physfs 2.0.2
I've updated physfs to v2 (2.0.2) in rawhide. It is backwards compatible with physfs v1, and I've already done local test rebuilds to confirm that. I have a chain-build running to rebuild all the packages that need it to avoid broken deps, but if I miss one, you should simply be able to increment Release and rebuild to resolve it. ~tom == Fedora Project -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: (re)introducing - fedora-review - tool to help with package reviews
On 11/21/2011 02:14 PM, Stanislav Ochotnicky wrote: Hello fellow devs, I am sure quite a few of you have done some reviews and thought "Hey, a,b,c and d could be automated. For E I could use some more information that can be automatically gathered". Some of you even wrote your own tools to do some of these things. Hi Stan, great idea. Will try to use this prior to any forthcoming reviews. I find the most time consuming task in the review process is the license check. I use a combination of find/head/grep commands to try and determine if some of the source files have differing licenses to the stated one in the spec. None of my methods guarantee 100% license detection, given the sheer number of licenses out there, although if we could consolidate all of the methods reviewers use for this we would have a nifty tool indeed. Not sure if this is something which should be part of this package or another entirely? regards, Brendan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: evolution-data-server 3.3.3 soname version bump in rawhide
On Thu, 2011-12-15 at 08:22 -0500, Stephen Gallagher wrote: > Could you provide a list of the dependent packages that you don't have > commit rights to, so we can organize a provenpackager to help handle it? Hi, I know this is not the right procedure, but can I provide it "after it breaks", please? I've a little mess in what is still active and what not, thus I get the list by the broken deps messages, which is more accurate than my outdated records. I'm sorry for that. I'm currently receiving broken deps for only two packages from the last soname bump of eds in rawhide, one is syncevolution, to which I have commit rights, but the issue is something with linking after its update to newer version - I didn't follow the error closely. The other is gnome-python2-desktop, to which I do not have commit rights. I do not have commit rights to others too, but owners are forgiving to me and usually rebuild their packages on their own. Bye, Milan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Heads-up: GIMP 2.7/2.8 in Rawhide, license change to (L)GPLv3+
Hi, I just finished with the Fedora 17 feature page for GIMP 2.8[1] and built gimp-2.7.4 into Rawhide. GIMP changed its licensing to GPLv3+ (app, included plugins) and LGPLv3+ (libraries) from the 2.7 development versions on. I've checked dependent packages and found that all are listed with compatible licenses in their spec files (CeCill v2, GPLv2+, GPLv3+, Public Domain). One minor licensing issues was introduced with this change, namely with poppler, used for importing PDFs and GPLv2 only. For the moment, GIMP packages from 2.7.x on won't use poppler, but the PostScript plugin for importing PDFs. This is a workaround until the next stable version poppler 0.20 which will be based off xpdf-3.03 (or later), thusly GPLv2/GPLv3 dual-licensed and compatible again. While APIs used by external plugins should be backwards-compatible, I'll rebuild packages using GIMP libraries (i.e. having GIMP plugins) against the current (not yet stable) version 2.7.4 and against the stable version when it's there, just to be on the safe side. These are the affected (source) packages: GREYCstoration: deebs gimp-fourier-plugin: fabiand gimp-lqr-plugin: slankes gimp-resynthesizer: ewan gimpfx-foundry: rvinyard gutenprint: twaugh - jpopelka mathmap: rnorwood ufraw: nphilipp xsane: nphilipp I plan to do the first round of rebuilds tomorrow, so if there's any reason why I shouldn't rebuild one of these, or you want to rebuild a package by yourself, speak up ;-). Nils [1]: https://fedoraproject.org/wiki/Features/GIMP_2.8 -- Nils Philippsen "Those who would give up Essential Liberty to purchase Red Hat a little Temporary Safety, deserve neither Liberty n...@redhat.com nor Safety." -- Benjamin Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Review swaps
I would like to swap reviews for the following. All are very tiny so feel free to swap 2 for one. Listed in descending priority: https://bugzilla.redhat.com/show_bug.cgi?id=767583 python-poppler-qt4 - Qt4 poppler bindings https://bugzilla.redhat.com/show_bug.cgi?id=760270 lv2-ams-plugins - LV2 port of the Alsa Modular Synth modules https://bugzilla.redhat.com/show_bug.cgi?id=766154 lv2-kn0ck0ut - An LV2 spectral subtraction plugin (linux audio) https://bugzilla.redhat.com/show_bug.cgi?id=754004 lv2-abGate - an LV2 Noise Gate plugin I will be able to commence reviews from next Wednesday, unless anyone anyone responds this evening. Thanks! Brendan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[perl-Mail-GnuPG/f15: 3/3] Merge cleanup.
commit 47fc27c758176d1068e85d18ee5102b9f5585dad Author: Ralf Corsépius Date: Thu Dec 15 18:49:54 2011 +0100 Merge cleanup. perl-Mail-GnuPG.spec |3 --- 1 files changed, 0 insertions(+), 3 deletions(-) --- diff --git a/perl-Mail-GnuPG.spec b/perl-Mail-GnuPG.spec index d23302e..211d435 100644 --- a/perl-Mail-GnuPG.spec +++ b/perl-Mail-GnuPG.spec @@ -53,9 +53,6 @@ GPG_PRESET_PASSPHRASE=/usr/libexec/gpg-preset-passphrase ./Build test * Thu Dec 15 2011 Ralf Corsépius < corse...@fedoraproject.org> - 0.17-1 - Upstream update. -* Tue Jul 19 2011 Petr Sabata - 0.16-3 -- Perl mass rebuild - * Tue Feb 08 2011 Fedora Release Engineering - 0.16-2 - Rebuilt for https://fedoraproject.org/wiki/Fedora_15_Mass_Rebuild -- 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
[perl-Mail-GnuPG/f15] (3 commits) ...Merge cleanup.
Summary of changes: c6e0116... Perl mass rebuild (*) c1fdfb9... Upstream update. (*) 47fc27c... Merge cleanup. (*) This commit already existed in another branch; no separate mail sent -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Mail-GnuPG/f16] Upstream update.
Summary of changes: c1fdfb9... Upstream update. (*) (*) This commit already existed in another branch; no separate mail sent -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Mail-GnuPG] Upstream update.
commit c1fdfb9de46baf6ffd4b680beca0e2a24dc30c58
Author: Ralf Corsépius
Date: Thu Dec 15 18:30:27 2011 +0100
Upstream update.
.gitignore |3 +--
perl-Mail-GnuPG.spec | 12 +---
sources |2 +-
3 files changed, 7 insertions(+), 10 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index 3e102d7..9cbc8f7 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1,2 +1 @@
-Mail-GnuPG-0.15.tar.gz
-/Mail-GnuPG-0.16.tar.gz
+/Mail-GnuPG-0.17.tar.gz
diff --git a/perl-Mail-GnuPG.spec b/perl-Mail-GnuPG.spec
index ef67c27..d23302e 100644
--- a/perl-Mail-GnuPG.spec
+++ b/perl-Mail-GnuPG.spec
@@ -1,11 +1,10 @@
Name: perl-Mail-GnuPG
Summary: Process email with GPG
-Version: 0.16
-Release: 3%{?dist}
+Version: 0.17
+Release: 1%{?dist}
License: GPLv2 or Artistic
Group: Development/Libraries
URL: http://search.cpan.org/dist/Mail-GnuPG/
-BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
BuildArch: noarch
Requires: perl(:MODULE_COMPAT_%(eval "`%{__perl} -V:version`"; echo
$version))
@@ -36,15 +35,11 @@ mv README~ README
./Build
%install
-rm -rf $RPM_BUILD_ROOT
./Build install destdir=$RPM_BUILD_ROOT create_packlist=0
find $RPM_BUILD_ROOT -depth -type d -exec rmdir {} 2>/dev/null \;
%{_fixperms} $RPM_BUILD_ROOT/*
-%clean
-rm -rf $RPM_BUILD_ROOT
-
%check
GPG_PRESET_PASSPHRASE=/usr/libexec/gpg-preset-passphrase ./Build test
@@ -55,6 +50,9 @@ GPG_PRESET_PASSPHRASE=/usr/libexec/gpg-preset-passphrase
./Build test
%{_mandir}/man3/*
%changelog
+* Thu Dec 15 2011 Ralf Corsépius < corse...@fedoraproject.org> - 0.17-1
+- Upstream update.
+
* Tue Jul 19 2011 Petr Sabata - 0.16-3
- Perl mass rebuild
diff --git a/sources b/sources
index 9bc6a84..4d2ac6b 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-ab13896e4410563c2c4f92f7de6684ae Mail-GnuPG-0.16.tar.gz
+b6c94307bcac31a4f6c7a47aa8065bd9 Mail-GnuPG-0.17.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
File Mail-GnuPG-0.17.tar.gz uploaded to lookaside cache by corsepiu
A file has been added to the lookaside cache for perl-Mail-GnuPG: b6c94307bcac31a4f6c7a47aa8065bd9 Mail-GnuPG-0.17.tar.gz -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: Systemd unit file alias question
On Mon, 21.11.11 15:37, Richard Shaw (hobbes1...@gmail.com) wrote: > I'm working on improving how akmods are built and had an idea[1] I > need input/confirmation on. > > Instead of the akmods packaging assuming when it needs to run, why > can't each akmod driver package provide it's own unit file? > > Since the service would run as type "oneshot", am I correct in > assuming that no matter how many times it's started, it will only > start for real on the first (earliest) occurrence? No, it will start whenever somebody requests it and it isn't already running on Type=oneshot. However, if you combine this with RemainAfterExit=yes you get the desired behaviour. > My idea is that each akmod driver package would provide a service file > with the same name as the package but include an alias to > "akmods.service". Not sure I understand this. Note that systemd will not allow aliases to be mapped to multiple units at the same time. > What's the consequences of multiple unit files claiming the same > alias? Is this safe? The first one will win, the others will result in an error message to be printed and ignored. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: evolution-data-server 3.3.3 soname version bump in rawhide
On Thu, 2011-12-15 at 09:47 +0100, Milan Crha wrote: > Hi, > just a note that the upcoming release of evolution-data-server 3.3.3 > contains soname version bumps for libcamel and libedatacal, as of today. > The release is planned for the next week. > > I'll rebuild broken deps packages the next day after the update lands to > the rawhide, at least those I've commit rights to (it'll be definitely > sooner than the last time). > Bye, > Milan Could you provide a list of the dependent packages that you don't have commit rights to, so we can organize a provenpackager to help handle it? 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: Native systemd unit for tsm client
On 12/15/2011 11:48 AM, Michal Schmidt wrote: If dsmcad is indeed forking, the type is correct. Don't lie to systemd. If dsmcad indeed creates no PID file, it's correct to not have the PIDFile= entry. If the main PID guessing can go wrong (for double-forking daemons that can happen), GuessMainPID=no is the right option to set. I see nothing wrong with that. I stand corrected and on top that for some weird reason the unit similar to what he was using works now [Unit] Description=Tivoly Storage Manager Client After=network.target [Service] Type=forking Environment=DSM_LOG=/var/log/tsm ExecStart=/usr/bin/dsmcad GuessMainPID=no [Install] WantedBy=multi-user.target # systemctl start tsm-client.service && systemctl status tsm-client.service && ps aux | grep dsmcad && netstat -pant | grep dsmcad tsm-client.service - Tivoly Storage Manager Client Loaded: loaded (/lib/systemd/system/tsm-client.service; disabled) Active: active (running) since Thu, 15 Dec 2011 12:08:32 +; 7ms ago Process: 7723 ExecStart=/usr/bin/dsmcad (code=exited, status=0/SUCCESS) CGroup: name=systemd:/system/tsm-client.service ├ 7724 [dsmcad] └ 7726 /usr/bin/dsmcad root 7726 0.0 0.1 310576 3044 ?Sl 12:08 0:00 /usr/bin/dsmcad root 7728 0.0 0.0 109240 884 pts/0S+ 12:08 0:00 grep --color=auto dsmcad tcp0 0 0.0.0.0:1581 0.0.0.0:* LISTEN 7726/dsmcad tcp0 0 0.0.0.0:56494 0.0.0.0:* LISTEN 7726/dsmcad # systemctl stop tsm-client.service && systemctl status tsm-client.service && ps aux | grep dsmcad && netstat -pant | grep dsmcad tsm-client.service - Tivoly Storage Manager Client Loaded: loaded (/lib/systemd/system/tsm-client.service; disabled) Active: inactive (dead) since Thu, 15 Dec 2011 12:09:53 +; 8ms ago Process: 7723 ExecStart=/usr/bin/dsmcad (code=exited, status=0/SUCCESS) CGroup: name=systemd:/system/tsm-client.service I cant explain why it did not work earlier this morning I guess blaming it on a lack of coffee is as an good excuse as any. JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Native systemd unit for tsm client
Jóhann B. Guðmundsson" wrote: > Nope nothing odd with specifying Type=oneshot together with > RemainAfterExit=yes Well, it is really odd to spacify oneshot if the service is actually a daemon. > # systemctl start tsm-client.service && systemctl status > tsm-client.service && ps aux | grep dsmcad && netstat -pant | grep > dsmcad > tsm-client.service - Tivoly Storage Manager Client >Loaded: loaded (/lib/systemd/system/tsm-client.service; >disabled) >Active: active (exited) since Thu, 15 Dec 2011 10:53:08 +; >8s ago > Process: 7312 ExecStart=/usr/bin/dsmcad (code=exited, > status=0/SUCCESS) >CGroup: name=systemd:/system/tsm-client.service >└ 7315 /usr/bin/dsmcad Notice the not-quite correct "active (exited)" state. If PID 7315 dies unexpectedly, your service would still show up as active. > You have Type=forking and GuessMainPID=no without having PIDFile= > entry > > The above seem odd to me about the unit file you are using If dsmcad is indeed forking, the type is correct. Don't lie to systemd. If dsmcad indeed creates no PID file, it's correct to not have the PIDFile= entry. If the main PID guessing can go wrong (for double-forking daemons that can happen), GuessMainPID=no is the right option to set. I see nothing wrong with that. Michal -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
octave-specfun: license change from GPLv2+ to GPLv3+
I'd like to push octave-specfun v1.1.0 to rawhide; octave-specfun changes the license from GPLv2+ to GPLv3+. The only package that depends on octave-specfun in the repository that I am aware of is octave-signal, and that is already GPLv3+. Are there any objections? Thanks, Tom -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
evolution-data-server 3.3.3 soname version bump in rawhide
Hi, just a note that the upcoming release of evolution-data-server 3.3.3 contains soname version bumps for libcamel and libedatacal, as of today. The release is planned for the next week. I'll rebuild broken deps packages the next day after the update lands to the rawhide, at least those I've commit rights to (it'll be definitely sooner than the last time). Bye, Milan ___ devel-announce mailing list devel-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel-announce -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
rawhide report: 20111215 changes
Compose started at Thu Dec 15 08:15:05 UTC 2011 Broken deps for x86_64 -- OpenGTL-0.9.15.1-3.fc17.x86_64 requires libLLVM-2.9.so()(64bit) OpenGTL-devel-0.9.15.1-3.fc17.i686 requires libLLVM-2.9.so OpenGTL-devel-0.9.15.1-3.fc17.x86_64 requires libLLVM-2.9.so()(64bit) OpenGTL-libs-0.9.15.1-3.fc17.i686 requires libLLVM-2.9.so OpenGTL-libs-0.9.15.1-3.fc17.x86_64 requires libLLVM-2.9.so()(64bit) banshee-2.2.1-2.fc17.x86_64 requires mono(gudev-sharp) = 0:1.0.0.0 boinc-manager-6.12.35-1.r24014svn.fc17.x86_64 requires libxcb-atom.so.1()(64bit) comoonics-cdsl-py-0.2-18.noarch requires comoonics-base-py comoonics-cluster-py-0.1-24.noarch requires comoonics-base-py compiz-0.9.5.92.1-0.1.gite676f1b12eb8db3a76978eed5bfc7c2cf9a0b6ce.fc17.i686 requires libboost_serialization-mt.so.1.47.0 compiz-0.9.5.92.1-0.1.gite676f1b12eb8db3a76978eed5bfc7c2cf9a0b6ce.fc17.x86_64 requires libboost_serialization-mt.so.1.47.0()(64bit) compiz-fusion-extras-0.9.5.92-1.fc17.x86_64 requires libboost_serialization-mt.so.1.47.0()(64bit) compiz-fusion-unsupported-0.9.4-6.fc17.x86_64 requires libboost_serialization-mt.so.1.47.0()(64bit) compiz-gtk-0.9.5.92.1-0.1.gite676f1b12eb8db3a76978eed5bfc7c2cf9a0b6ce.fc17.x86_64 requires libboost_serialization-mt.so.1.47.0()(64bit) compiz-kde-0.9.5.92.1-0.1.gite676f1b12eb8db3a76978eed5bfc7c2cf9a0b6ce.fc17.x86_64 requires libboost_serialization-mt.so.1.47.0()(64bit) compiz-plugins-main-0.9.5.92-1.fc17.x86_64 requires libboost_serialization-mt.so.1.47.0()(64bit) contextkit-0.5.15-2.fc15.i686 requires libcdb.so.1 contextkit-0.5.15-2.fc15.x86_64 requires libcdb.so.1()(64bit) couchdb-1.0.3-2.fc16.x86_64 requires libicuuc.so.46()(64bit) couchdb-1.0.3-2.fc16.x86_64 requires libicui18n.so.46()(64bit) couchdb-1.0.3-2.fc16.x86_64 requires libicudata.so.46()(64bit) curry-0.9.11-7.fc12.x86_64 requires libgmp.so.3()(64bit) dh-make-0.55-3.fc15.noarch requires debhelper ekg2-xosd-0.2-0.17.rc1.fc16.x86_64 requires libxosd.so.2()(64bit) firefox-8.0-3.fc17.x86_64 requires gecko-libs(x86-64) = 0:8.0 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) gcc-python2-debug-plugin-0.7-1.fc17.x86_64 requires gcc = 0:4.6.2-1.fc17 gcc-python2-plugin-0.7-1.fc17.x86_64 requires gcc = 0:4.6.2-1.fc17 gcc-python3-debug-plugin-0.7-1.fc17.x86_64 requires gcc = 0:4.6.2-1.fc17 gcc-python3-plugin-0.7-1.fc17.x86_64 requires gcc = 0:4.6.2-1.fc17 gearmand-0.23-2.fc17.x86_64 requires libboost_program_options-mt.so.1.47.0()(64bit) genius-1.0.12-2.fc15.x86_64 requires libgmp.so.3()(64bit) gnome-genius-1.0.12-2.fc15.x86_64 requires libgmp.so.3()(64bit) gnome-python2-evolution-2.32.0-6.fc17.x86_64 requires libebook-1.2.so.12()(64bit) gphpedit-0.9.95-0.2.20090209snap.fc15.x86_64 requires libgtkhtml-2.so.0()(64bit) gpsdrive-2.11-10.fc17.x86_64 requires libmapnik.so.0.7()(64bit) gpsdrive-2.11-10.fc17.x86_64 requires libboost_thread-mt.so.1.47.0()(64bit) gpsdrive-2.11-10.fc17.x86_64 requires libboost_system-mt.so.1.47.0()(64bit) gpsdrive-2.11-10.fc17.x86_64 requires libboost_filesystem-mt.so.1.47.0()(64bit) gpx-viewer-0.2.0-3.fc14.x86_64 requires libgdl-1.so.3()(64bit) gpx-viewer-0.2.0-3.fc14.x86_64 requires libclutter-gtk-0.10.so.0()(64bit) gpx-viewer-0.2.0-3.fc14.x86_64 requires libclutter-glx-1.0.so.0()(64bit) gpx-viewer-0.2.0-3.fc14.x86_64 requires libchamplain-gtk-0.6.so.0()(64bit) gpx-viewer-0.2.0-3.fc14.x86_64 requires libchamplain-0.6.so.0()(64bit) gscribble-0.1.2-1.fc16.noarch requires gnome-python2-gtkhtml2 gstreamer-java-swt-1.5-1.fc16.x86_64 requires libswt3-gtk2 hamlib-1.2.14-2.fc17.i686 requires libusrp-3.4.2.so.0 hamlib-1.2.14-2.fc17.x86_64 requires libusrp-3.4.2.so.0()(64bit) hosts3d-1.13-2.fc15.x86_64 requires libglfw.so.2.6()(64bit) hosts3d-sampler-1.13-2.fc15.x86_64 requires libglfw.so.2.6()(64bit) i3-4.0.1-2.fc17.x86_64 requires libxcb-property.so.1()(64bit) i3-4.0.1-2.fc17.x86_64 requires libxcb-keysyms.so.1()(64bit) i3-4.0.1-2.fc17.x86_64 requires libxcb-icccm.so.1()(64bit) i3-4.0.1-2.fc17.x86_64 requires libxcb-event.so.1()(64bit) i3-4.0.1-2.fc17.x86_64 requires libxcb-aux.so.0()(64bit) i3-4.0.1-2.fc17.x86_64 requires libxcb-atom.so.1()(64bit) intellij-idea-9.0.1.94.399-12.fc15.x86_64 requires commons-collections kde-partitionmanager-1.0.3-2.fc15.x86_64 requires libparted.so.0()(64bit) 6:kdeutils-4.7.90-1.fc17.noarch requires superkaramba >= 0:4.7.90 6:kdeutils-4.7.90-1.fc17.noarch requires kremotecontro
Re: Fedora 16 for IBM System z 64bit official release
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Congratulations. I'm fan of this team. Em 15-12-2011 09:02, Dan Horák escreveu: > There was still a longer delay after the Fedora 16 release for the > primary architectures than we would like to see, but at least we are > faster than with Fedora 15 and so here we are. > > As today, the Fedora IBM System z (s390x) Secondary Arch team proudly > presents the Fedora 16 for IBM System z 64bit official release! > > The links to the actual release are here: > > http://secondary.fedoraproject.org/pub/fedora-secondary/releases/16/Fedora/s390x/ > > http://secondary.fedoraproject.org/pub/fedora-secondary/releases/16/Everything/s390x/os/ > > and obviously on all mirrors that mirror the secondary arch content. > > The first directory contains the normal installation trees as well as > one DVD ISO with the complete release. > > Everything as usual contains, well, everything. :) > > > Additional information about known issues, the current progress and state > for future release, where and how the team can be reached and just > anything else IBM System z on Fedora related can be found here: > > > http://fedoraproject.org/wiki/Architectures/s390x/16 > for architecture specific release notes > > and > > http://fedoraproject.org/wiki/Architectures/s390x > for the general information. > > > Thanks go out to everyone involved in making this happen! > > > Your Fedora/s390x Maintainers > - -- Lucélio Gomes de Freitas ETFCSF-> U.G.F.-> P.U.C.(RJ) Engº, Analista Suporte(Free Mind). Email: aa.luce...@gmail.com Tel: 55 0XX 21 85964911 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iF4EAREIAAYFAk7p1vEACgkQENqGaHfBA/fmvAEAhFeD0aHjeCl8A/9aeeJaODIb 7FAmZCHnkzseFpg7DAYA/iAQz7PGK4WEQCZvNhImK/Berrrz//Oqp1XK8qZpcSEw =XiTr -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Native systemd unit for tsm client
On 12/15/2011 10:38 AM, Thomas Moschny wrote: 2011/12/15 "Jóhann B. Guðmundsson": Hum that unit file looks a bit odd to me and does not work with TSM 6.3 on F16 atleast not here Not sure what you mean by "a bit odd". Isn't specifying "oneshot" together with "RemainAfterExit" more odd in this case, where a deamon (dsmcad) in fact keeps running? Is it possible to stop it with your unit file? pe Nope nothing odd with specifying Type=oneshot together with RemainAfterExit=yes however having RemainAfterExit with Type=forking or Type=simple would be odd Starting the unit... # systemctl start tsm-client.service && systemctl status tsm-client.service && ps aux | grep dsmcad && netstat -pant | grep dsmcad tsm-client.service - Tivoly Storage Manager Client Loaded: loaded (/lib/systemd/system/tsm-client.service; disabled) Active: active (exited) since Thu, 15 Dec 2011 10:53:08 +; 8s ago Process: 7312 ExecStart=/usr/bin/dsmcad (code=exited, status=0/SUCCESS) CGroup: name=systemd:/system/tsm-client.service └ 7315 /usr/bin/dsmcad root 7315 0.0 0.2 318976 4100 ?Sl 10:53 0:00 /usr/bin/dsmcad root 7325 0.0 0.0 109240 888 pts/0S+ 10:53 0:00 grep --color=auto dsmcad tcp0 0 0.0.0.0:51833 0.0.0.0:* LISTEN 7315/dsmcad tcp0 0 0.0.0.0:1581 0.0.0.0:* LISTEN 7315/dsmcad Stopping the unit # systemctl stop tsm-client.service && systemctl status tsm-client.service && ps aux | grep dsmcad && netstat -pant | grep dsmcad tsm-client.service - Tivoly Storage Manager Client Loaded: loaded (/lib/systemd/system/tsm-client.service; disabled) Active: inactive (dead) since Thu, 15 Dec 2011 10:55:52 +; 6ms ago Process: 7312 ExecStart=/usr/bin/dsmcad (code=exited, status=0/SUCCESS) CGroup: name=systemd:/system/tsm-client.service From where I'm standing I would consider that startup and shutdown of the unit as clean as it gets... The one I posted works with 6.2.2 on Fedora 16 x86_64. The only "odd" thing might be that it doesn't use the pid file but cgroups to control the daemon - which is a good thing anyway. Why are you ignoring exit code of the start command which would otherwise normally be considered a failure? There is no need for this line StandardOutput=syslog it's the default You have Type=forking and GuessMainPID=no without having PIDFile= entry The above seem odd to me about the unit file you are using JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora 16 for IBM System z 64bit official release
There was still a longer delay after the Fedora 16 release for the primary architectures than we would like to see, but at least we are faster than with Fedora 15 and so here we are. As today, the Fedora IBM System z (s390x) Secondary Arch team proudly presents the Fedora 16 for IBM System z 64bit official release! The links to the actual release are here: http://secondary.fedoraproject.org/pub/fedora-secondary/releases/16/Fedora/s390x/ http://secondary.fedoraproject.org/pub/fedora-secondary/releases/16/Everything/s390x/os/ and obviously on all mirrors that mirror the secondary arch content. The first directory contains the normal installation trees as well as one DVD ISO with the complete release. Everything as usual contains, well, everything. :) Additional information about known issues, the current progress and state for future release, where and how the team can be reached and just anything else IBM System z on Fedora related can be found here: http://fedoraproject.org/wiki/Architectures/s390x/16 for architecture specific release notes and http://fedoraproject.org/wiki/Architectures/s390x for the general information. Thanks go out to everyone involved in making this happen! Your Fedora/s390x Maintainers -- Dan Horák, RHCE Senior Software Engineer, BaseOS Red Hat Czech s.r.o., Purkyňova 99, 612 45 Brno -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Native systemd unit for tsm client
2011/12/15 "Jóhann B. Guðmundsson" : > Hum that unit file looks a bit odd to me and does not work with TSM 6.3 on > F16 atleast not here Not sure what you mean by "a bit odd". Isn't specifying "oneshot" together with "RemainAfterExit" more odd in this case, where a deamon (dsmcad) in fact keeps running? Is it possible to stop it with your unit file? The one I posted works with 6.2.2 on Fedora 16 x86_64. The only "odd" thing might be that it doesn't use the pid file but cgroups to control the daemon - which is a good thing anyway. - Thomas -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Native systemd unit for tsm client
On 12/15/2011 09:08 AM, Thomas Moschny wrote: Why are you starting dsmc explicitly - isn't it started by dsmcad? You are right not worry about "dsmc sched" as dsmcad will call dsmc sched and also control the webclient portion so you can just drop that line. Probably a nasty habit from I picked up from the past throwing it in there... ### tsm-client.service ### [Unit] Description=Tivoly Storage Manager Client After=network.target [Service] Type=oneshot Environment=DSM_LOG=/var/log/tsm ExecStart=/usr/bin/dsmcad RemainAfterExit=yes [Install] WantedBy=multi-user.target Here's what we've been using: [Unit] Description=DSM Client Acceptor After=network.target [Service] Type=forking ExecStart=-/usr/bin/dsmcad -errorlogname=/var/log/dsmerror.log Environment=LANG=en_US StandardOutput=syslog GuessMainPID=no [Install] WantedBy=multi-user.target For some reason the PID guessing does not work, so we force it to use cgroups. Hum that unit file looks a bit odd to me and does not work with TSM 6.3 on F16 atleast not here anywho the IBM guys/gal will probably come up eventually with the official and "correct" unit for their client when RHEL7 gets released and maybe stop polluting 64bit installs with dependency's on i386 but as you probably already know if wishes were horses we would all be eating steak... JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Yum translation update request
Hi. How's it going? https://bugzilla.redhat.com/show_bug.cgi?id=726878 http://lists.fedoraproject.org/pipermail/trans/2011-December/009532.html -- 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: Native systemd unit for tsm client
Why are you starting dsmc explicitly - isn't it started by dsmcad? Here's what we've been using: [Unit] Description=DSM Client Acceptor After=network.target [Service] Type=forking ExecStart=-/usr/bin/dsmcad -errorlogname=/var/log/dsmerror.log Environment=LANG=en_US StandardOutput=syslog GuessMainPID=no [Install] WantedBy=multi-user.target For some reason the PID guessing does not work, so we force it to use cgroups. - Thomas 2011/12/15 "Jóhann B. Guðmundsson" : > Here's an native tsm client service for your fedora running > workstation/server since it's probably going to be awhile before IBM catches > up to systemd... > > ### tsm-client.service ### > > [Unit] > Description=Tivoly Storage Manager Client > After=network.target > > [Service] > Type=oneshot > Environment=DSM_LOG=/var/log/tsm > ExecStart=/usr/bin/dsmcad > ExecStart=/bin/bash -c "exec /usr/bin/dsmc sched > /dev/null 2>&1 &" > RemainAfterExit=yes > > [Install] > WantedBy=multi-user.target > -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
rubygem-bcrypt-ruby license change
Hi, rubygem-bcrypt-ruby has changed its license from "BSD with advertising and MIT" to "MIT and Public Domain and ISC" due to changes in its internal C implementation. Cheers, Vít -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
