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 upda
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 wrote:
> >
> > > I'm not sure we can treat scratch / personal builds with *quite* so
> > > much abandon. They're still
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/p
On 6 December 2011 20:18, Ralf Ertzinger 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 _your_username
On Wed, Dec 7, 2011 at 11: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.
+1 as a c
On Wed, 07 Dec 2011 10:13:24 -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
> > tm
commit 45ca4e4e816ab4e61b17f4de48ec5daba93ac41f
Author: Emmanuel Seyman
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 +
...ndom-0.06-Check-if-_to_secs-returns-undef.patc
>
> Date: Wed, 07 Dec 2011 16:01:06 +0100
> From: Richard Marko
>
> 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
> be shared f
On Wed, 2011-12-07 at 16:15 -0500, seth vidal wrote:
> On Wed, 07 Dec 2011 15:02:42 -0500
> Przemek Klosowski 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 binar
On Wed, 07 Dec 2011 13:25:28 -0800
Adam Williamson 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 to reliably reprod
On Wed, 2011-12-07 at 18:12 -0500, seth vidal wrote:
> On Wed, 07 Dec 2011 13:25:28 -0800
> Adam Williamson 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.
>
>
2011/12/7 Nicolas Mailhot
> 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 centralised
Koji servers f
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 ov
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 just
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 t
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
> > >
On Thu, 08 Dec 2011 05:35:02 +0900
夜神 岩男 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 is not that huge of a
On Wed, 07 Dec 2011 15:02:42 -0500
Przemek Klosowski 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 (and running) softw
On Thu, 08 Dec 2011 04:34:57 +0900
夜神 岩男 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 for a widespread comprom
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 whe
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
On 12/07/2011 01:40 PM, seth vidal wrote:
> On Wed, 07 Dec 2011 13:35:03 -0500
> Mo Morsi 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?
>> >
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
On Wed, 07 Dec 2011 13:35:03 -0500
Mo Morsi 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 pursuing th
On Wed, 7 Dec 2011 18:31:27 +0100
Denis Arnaud wrote:
> 2011/12/7 seth vidal
>
> > 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 n
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:
> > > >
2011/12/7 seth vidal
> 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 the builds with their
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
On Tue, 06 Dec 2011 15:08:09 +0100
Roman Rakus 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 specific
kernels
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 t
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 Rent-A-Center
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 "syste
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 "syste
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 di
On Wed, 7 Dec 2011 14:46:18 +0100
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 s
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
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,
On Wed, Dec 7, 2011 at 8:46 AM, 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
> servi
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
a
40 matches
Mail list logo
