Hello,
RedHat-hosted Koji servers offer an invaluable service by allowing all of
us, package maintainers, to build all of our Fedora packages. I guess
that that infrastructure is not cost-less for RedHat and and the quality of
service is great (for instance, the wait in the queues, before Koji
On Wed, Dec 7, 2011 at 8:46 AM, Denis Arnaud
denis.arnaud_fed...@m4x.org wrote:
Hello,
RedHat-hosted Koji servers offer an invaluable service by allowing all of
us, package maintainers, to build all of our Fedora packages. I guess that
that infrastructure is not cost-less for RedHat and and
Hi,
I'm an upstream OpenNebula developer, and it's nice to hear that
you've been packaging Ruby gems required by the OpenNebula package.
Currently I've been working with Shawn Starr (CC) on the OpenNebula
package, and for the moment the issue has been mostly with Ruby gems
dependencies, so
On 12/07/2011 02:46 PM, Denis Arnaud wrote:
Hello,
RedHat-hosted Koji servers offer an invaluable service by allowing all
of us, package maintainers, to build all of our Fedora packages. I
guess that that infrastructure is not cost-less for RedHat and and the
quality of service is great
On Wed, 7 Dec 2011 14:46:18 +0100
Denis Arnaud denis.arnaud_fed...@m4x.org wrote:
Hello,
RedHat-hosted Koji servers offer an invaluable service by allowing
all of us, package maintainers, to build all of our Fedora
packages. I guess that that infrastructure is not cost-less for
RedHat and
The vnstat service has traditionally run as the root user. This was
fixed in Fedora 16 and higher to run as the vnstat user, but the same
fix was just introduced[1] into Fedora 15. There is a problem with this
fix in that it requires systemd-tmpfiles to be run to create the new
/run/vnstat
On 12/07/2011 03:37 PM, Michael Cronenworth wrote:
The vnstat service has traditionally run as the root user. This was
fixed in Fedora 16 and higher to run as the vnstat user, but the same
fix was just introduced[1] into Fedora 15. There is a problem with this
fix in that it requires
Paul Howarth wrote:
Simplest way is just to include the directory in the RPM in the same way
as you would if it was anywhere else in the filesystem. That caters for
operation immediately after installation, and the tmpfiles script can
re-create it on reboot.
The /run/vnstat directory must
On 12/07/2011 03:37 PM, Michael Cronenworth wrote:
The vnstat service has traditionally run as the root user. This was
fixed in Fedora 16 and higher to run as the vnstat user, but the same
fix was just introduced[1] into Fedora 15. There is a problem with this
fix in that it requires
Hello developers/packagers,
My name is Jayson Vaughn. I'm a member of the Fedora QA team
(proventesters) and Fedora bugzapper team.
Now, I am very interested and willing to assist with RPM packaging or
package maintenance.
I am a professional systems engineer and currently work for
On Wed, Dec 07, 2011 at 10:13:24AM -0600, Michael Cronenworth wrote:
Paul Howarth wrote:
Simplest way is just to include the directory in the RPM in the same way
as you would if it was anywhere else in the filesystem. That caters for
operation immediately after installation, and the
On Tue, 06 Dec 2011 15:08:09 +0100
Roman Rakus rra...@redhat.com wrote:
Thanks all for answers. And I will get back to this point. I will
change GRUB_CMDLINE_LINUX variable and run grub2-mkconfig. Hopefully
it will not brake anything.
It will break... everything. Any custom boot options for
Paul Howarth wrote:
How about using the vnstatd --pidfile option in the initscript rather
than adding it into the config file?
That's a good idea.
Thanks Paul, Toshio, and Johann. I'll go to the maintainer now with
these ideas.
P.S. It seems Fedora e-mail is being delayed (not sure if it is
2011/12/7 seth vidal skvi...@fedoraproject.org
I've looked into spawning virt instances to do building and it is pretty
doable. The problem with them being offered by volunteers is trust
[...]
You are right. I had not thought at that... how naive of me :(
The volunteers/trustees would sign
Il giorno sab, 03/12/2011 alle 22.58 -0800, Toshio Kuratomi ha scritto:
On Sat, Dec 03, 2011 at 04:13:37PM +0100, Giovanni Campagna wrote:
Il giorno ven, 02/12/2011 alle 16.37 -0800, Toshio Kuratomi ha scritto:
On Fri, Dec 02, 2011 at 09:39:31PM +0100, Giovanni Campagna wrote:
On Wed, 7 Dec 2011 18:31:27 +0100
Denis Arnaud denis.arnaud_fed...@m4x.org wrote:
2011/12/7 seth vidal skvi...@fedoraproject.org
I've looked into spawning virt instances to do building and it is
pretty doable. The problem with them being offered by volunteers is
trust [...]
You are
On Wed, 07 Dec 2011 13:35:03 -0500
Mo Morsi mmo...@redhat.com wrote:
On 12/07/2011 01:25 PM, seth vidal wrote:
That would be very cool. Do you intend to use DeltaCloud (
http://deltacloud.apache.org/), or something like that?
I'm using libcloud, actually. I'm interested in
Le mercredi 07 décembre 2011 à 10:36 -0500, seth vidal a écrit :
I've looked into spawning virt instances to do building and it is
pretty doable. The problem with them being offered by volunteers is
trust:
1. how do we trust the initial installation hasn't been poisoned unless
we ship all
On 12/07/2011 01:40 PM, seth vidal wrote:
On Wed, 07 Dec 2011 13:35:03 -0500
Mo Morsimmo...@redhat.com wrote:
On 12/07/2011 01:25 PM, seth vidal wrote:
That would be very cool. Do you intend to use DeltaCloud (
http://deltacloud.apache.org/), or something like that?
I'm
On 12/07/2011 01:25 PM, seth vidal wrote:
That would be very cool. Do you intend to use DeltaCloud (
http://deltacloud.apache.org/), or something like that?
I'm using libcloud, actually. I'm interested in pursuing this in
python, not ruby.
Deltacloud's primary interface is REST
On Wed, Dec 07, 2011 at 02:23:05PM +0100, Giovanni Campagna wrote:
Il giorno sab, 03/12/2011 alle 22.58 -0800, Toshio Kuratomi ha scritto:
Yep. This is a pseudo-bug. Because of the way people have been
interpreting the spec for .desktop files, all of these provide .desktop
files where the
On Thu, 08 Dec 2011 04:34:57 +0900
夜神 岩男 supergiantpot...@yahoo.co.jp wrote:
An idea just struck me that may work.
If the system is made light enough that it is utterly painless for
anyone to contribute processing time then cross-checking of hashes
could be made statistically secure, save
On Wed, 07 Dec 2011 15:02:42 -0500
Przemek Klosowski przemek.klosow...@nist.gov wrote:
On 12/07/2011 01:25 PM, seth vidal wrote:
If I were going to use random vm's I'd want to:
1. connect using ssh
2. push over my own rpm/python/etc binaries
3. checksum all the rest of the installed
On Thu, 08 Dec 2011 05:35:02 +0900
夜神 岩男 supergiantpot...@yahoo.co.jp wrote:
On 12/08/2011 05:12 AM, seth vidal wrote:
Bandwidth is the big concern for the end user here and then the
other issue is - is all of this worth it for building pkgs? I
don't think it is, personally, pkg building
Toshio Kuratomi (a.bad...@gmail.com) said:
As for repodata, you mention tags, but I can't find them here, in
primary, comps or other (and I don't see anything else in mirrors).
I hit a mirror and browsed around. Here's the one for the F16 x86_64
update
repo:
On 12/08/2011 05:12 AM, seth vidal wrote:
Bandwidth is the big concern for the end user here and then the other
issue is - is all of this worth it for building pkgs? I don't think it
is, personally, pkg building is not that huge of a hit, afaict to
getting things done.
I mean the sum total
An idea just struck me that may work.
If the system is made light enough that it is utterly painless for
anyone to contribute processing time then cross-checking of hashes could
be made statistically secure, save for a widespread compromise of the
entire Fedora userbase.
For example, if I
On 12/07/2011 01:25 PM, seth vidal wrote:
If I were going to use random vm's I'd want to:
1. connect using ssh
2. push over my own rpm/python/etc binaries
3. checksum all the rest of the installed (and running) software
4. verify those checksums versus my known good set
5. THEN push over
2011/12/7 Nicolas Mailhot nicolas.mail...@laposte.net
Concerning trust, the classic way it has been solved before (by seti…)
is to farm the same build to several independant nodes, cheksum results
and make sure they all agree
Again, we could use that P2P build system just to alleviate the
On Wed, 2011-12-07 at 18:12 -0500, seth vidal wrote:
On Wed, 07 Dec 2011 13:25:28 -0800
Adam Williamson awill...@redhat.com wrote:
I'm not sure we can treat scratch / personal builds with *quite* so
much abandon. They're still valuable targets for anyone trying to
compromise Fedora,
On Wed, 07 Dec 2011 13:25:28 -0800
Adam Williamson awill...@redhat.com wrote:
I'm not sure we can treat scratch / personal builds with *quite* so
much abandon. They're still valuable targets for anyone trying to
compromise Fedora, after all.
I don't think you understand - we need to be able
On Wed, 2011-12-07 at 16:15 -0500, seth vidal wrote:
On Wed, 07 Dec 2011 15:02:42 -0500
Przemek Klosowski przemek.klosow...@nist.gov wrote:
On 12/07/2011 01:25 PM, seth vidal wrote:
If I were going to use random vm's I'd want to:
1. connect using ssh
2. push over my own
Date: Wed, 07 Dec 2011 16:01:06 +0100
From: Richard Marko rma...@redhat.com
I'm currently writing a proposal of similar architecture for testing
purposes. Looks like the core -- community provided virtual machines is
the common component for all this stuff so if designed correctly it can
commit 45ca4e4e816ab4e61b17f4de48ec5daba93ac41f
Author: Emmanuel Seyman emmanuel.sey...@club-internet.fr
Date: Wed Dec 7 20:44:42 2011 +0100
Update to 0.06, refresh patch, clean up spec file and enable all tests
.gitignore |1 +
On Wed, 07 Dec 2011 10:13:24 -0600
Michael Cronenworth m...@cchtml.com wrote:
Paul Howarth wrote:
Simplest way is just to include the directory in the RPM in the
same way as you would if it was anywhere else in the filesystem.
That caters for operation immediately after installation, and
On Wed, Dec 7, 2011 at 11:12 AM, seth vidal skvi...@fedoraproject.org wrote:
Bandwidth is the big concern for the end user here and then the other
issue is - is all of this worth it for building pkgs? I don't think it
is, personally, pkg building is not that huge of a hit, afaict to
getting
On 6 December 2011 20:18, Ralf Ertzinger fed...@camperquake.de wrote:
Hi.
On Mon, 05 Dec 2011 16:15:42 -0800, Adam Williamson wrote
Couldn't run /usr/sbin/dumpcap in child process: Permission denied
Are you a member of the 'wireshark' group? Try running
'usermod -a -G wireshark
open-vm-tools for recent Fedora 15 kernels and VMware-HA/dataRecovery
see below
Am 08.12.2011 01:19, schrieb Marcelo Vanzin:
On 12/07/2011 04:14 PM, Reindl Harald wrote:
Patch #2 (open-vm-tools-vsync.patch): + /bin/cat
/home/builduser/rpmbuild/SOURCES/open-vm-tools-vsync.patch + /usr/bin/patch
On Wed, Dec 07, 2011 at 03:25:18PM -0800, Adam Williamson wrote:
On Wed, 2011-12-07 at 18:12 -0500, seth vidal wrote:
On Wed, 07 Dec 2011 13:25:28 -0800
Adam Williamson awill...@redhat.com wrote:
I'm not sure we can treat scratch / personal builds with *quite* so
much abandon.
I know the post I'm replying to is off-topic, but just to clarify the part
which may be relevant for Fedora packages:
Reindl Harald wrote:
below a list of packages which i maintain locally
mots of them only cpu-optimized rebuilds
many of them changed
* services MUST NOT restart while update
A file has been added to the lookaside cache for perl-IO-Socket-SSL:
d4ea32802f27db54df18c8455936a18d IO-Socket-SSL-1.52.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
commit f26c71c8d441dd0d5503f4475750921339a2b08f
Author: Paul Howarth p...@city-fan.org
Date: Wed Dec 7 11:13:39 2011 +
Update to 1.52
- New upstream release 1.52:
- Fix for t/nonblock.t hangs on AIX (CPAN RT#72305)
- Disable t/memleak_bad_handshake.t on AIX, because
Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.
Summary: perl-Bio-SamTools-1.33 is available
https://bugzilla.redhat.com/show_bug.cgi?id=760944
Summary: perl-Bio-SamTools-1.33 is available
Product: Fedora
The lightweight tag 'perl-IO-Socket-SSL-1.52-1.fc17' was created pointing to:
f26c71c... Update to 1.52
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
On Tue, Dec 06, 2011 at 06:23:43PM +0100, Jan Kasprzak wrote:
Marcela Mašláňová wrote:
: On 12/02/2011 04:34 PM, Jan Kasprzak wrote:
: Welcome to Perl packaging for Fedora.
:
: Paul (one of sponsors) was already looking at your review, but because
: of license it could take more time.
45 matches
Mail list logo
