Re: Fedora default services (was: Re: F15 Feature - convert as many service init files as possible to the native SystemD services)

On Sat, Dec 11, 2010 at 4:57 AM, Kevin Kofler wrote: > Bill Nottingham wrote: > > Right. To do this in systemd implies that you're patching openssh to > > do socket-based activation... hence why I asked about upstream's opinion > > on it. > > Why would we care? > > It's our goal to have ALL networ

Re: Proposed package blocking due to FTBFS

On Sat, Dec 11, 2010 at 01:44:54AM +0100, Kevin Kofler wrote: > Matt Domsch wrote: > > Last built on Fedora 12 (52): > > Huh? > > The right metric is not "when was this last built" but "when was this last > BUILDABLE". We don't randomly rebuild stuff which doesn't need to be > rebuilt. > > E.g

Re: hosted reproducible package building with multiple developers?

Till Maas wrote: > I guess giving someone a shell account in a VM is usually not less safe > than giving someone shell access on the host of the VM, as long as the > VM does not use kvm and does not run as root. By "does not use kvm", you mean pure software emulation? Enjoy the factor 50 slowdown

Re: Vacation/devaway system

Stanislav Ochotnicky wrote: > I know we have [1], but as you can see, there are 4 people listed on > that page. That leads me to believe two things: > 1. Most people don't know the page exists (I didn't until tibbs > pointed it out to me) > 2. It's cumbersome to edit wiki for things like this

Re: ABRT opt-out (was Re: Summary/Minutes from today's FESCo meeting)

drago01 wrote: > Well ABRT should stop filing bugs in bugzilla, it does not scale PERIOD. IMHO it should file bugs in the upstream bug tracker (even if that tracker is not Bugzilla, so it'd have to learn as many different bug tracker APIs as possible). Gnash upstream actually MIGHT be able to d

Re: Is there any value to per-Fedora branch ACLs?

Jesse Keating wrote: > Is anybody seeing any real value of having different commit ACLs per > Fedora branch? I've seen some argument for EPEL vs Fedora, but is there > real value in ACLs for f13, f14, devel, etc...? No. But the real question is: Is there any value to ACLs at all? Before the big

Re: Is there any value to per-Fedora branch ACLs?

Toshio Kuratomi wrote: > 2) Bodhi work on a per-branch level. Storing critpath information in > pkgdb pretty much means that we have to keep separate records for separate > releases. Why not just get rid of this critpath nonsense which doesn't work anyway? Kevin Kofler -- devel mailing

Re: ABRT opt-out (was Re: Summary/Minutes from today's FESCo meeting)

On Fri, Dec 10, 2010 at 10:51:39AM +0100, Jiri Moskovcak wrote: > > The problem is entirely cosmetic. No data is harmed, the program exits > > after that, it's just a child thread and the main process don't > > communicate the exit quite right. So, pretty much everyone who uses > > calibre se

Re: Proposed package blocking due to FTBFS

Toshio Kuratomi wrote: > They shouldn't have to go through a re-review unless they've let the > package sit in retirement for (I believe it's six months but someone else > might have the policy URL handy). Only 3 months. And if the package doesn't build, the maintainer is probably not going to c

Re: Proposed package blocking due to FTBFS

Kevin Fenzi wrote: > Have you considered training up some bugzappers to help triage your > components? They could at least work on de-duping abrt reports. Uh, I've pretty much given up on handling ABRT reports entirely. Even if they were deduped, there are so many different Gnash crashes that's

Re: Proposed package blocking due to FTBFS

Matt Domsch wrote: > Last built on Fedora 12 (52): Huh? The right metric is not "when was this last built" but "when was this last BUILDABLE". We don't randomly rebuild stuff which doesn't need to be rebuilt. E.g.: > celestia-1.5.1-2.fc12 [u'631077 NEW'] (build/make) steve,mmahut (the first on

Re: Fedora default services (was: Re: F15 Feature - convert as many service init files as possible to the native SystemD services)

Chris Adams wrote: > The only thing you need a firewall by default for is to prevent services > that are listening on the network from being accessible. The better > solution is to stop having services listen on the network by default. FWIW, this is what Ubuntu has been doing for ages (they call

Re: Firewall

2010/12/10 Kevin Kofler : > seth vidal wrote: >> ah, printing. >> >> Is there anything that's not last century? > > Uh, you'd be surprised how much many users out there in the real world still > print! > In these days I've been printing 2+ pages, all of them different, and I do it in a network

Re: Firewall

seth vidal wrote: > ah, printing. > > Is there anything that's not last century? Uh, you'd be surprised how much many users out there in the real world still print! Sure, I don't use my printer much anymore, and there might even be people not printing anything at all anymore, you might be one

Re: Firewall

seth vidal wrote: > what network games? > Heck, what network games do we HAVE? Wesnoth! And a few others, too. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Firewall

Chris Adams wrote: > Congrats, you have re-invented UPnP, although a local-only version > maybe (not that I think that is necessarily a bad thing). Hmmm, indeed, KDE is moving towards using UPnP for more and more things, it'd be nice if it were used throughout Fedora, or at least supported by wh

Re: Fedora default services (was: Re: F15 Feature - convert as many service init files as possible to the native SystemD services)

Bill Nottingham wrote: > Right. To do this in systemd implies that you're patching openssh to > do socket-based activation... hence why I asked about upstream's opinion > on it. Why would we care? It's our goal to have ALL network daemons be socket-activated eventually. This is a distribution-wi

Re: Fedora as semantic desktop (nautilus and tracker integration) ?

valent.turko...@gmail.com wrote: > https://bugzilla.redhat.com/show_bug.cgi?id=501227 > > I'm writing to devel list just if anybody can say will there be any > chance to get nautilus and tracker integration working? Is this on > anybody's radar? Well, try Dolphin with Nepomuk integration. :-)

Re: mpfr soname bump in rawhide

Josh Boyer wrote: > Encouraging openness and cooperation by threatening verbal abuse in > the event of a mistake is not something the Fedora project wants to > condone. Education and cooperative resolution of the problem is. Uhm, no, bureaucracy and stubborn-by-design software is. :-( I'd much r

Re: Unresponsive maintainer for libical

Milan Crha wrote: > so I added myself to the package, and it's waiting for a review now. It > might be done by 'robert' [1], who is the only maintainer of libical at > the moment. "robert" is Robert Scheck. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.f

Re: old_testing_critpath notifications

Bruno Wolff III wrote: > I am concerned about that. If my karma is going to be treated differently > because I become a proventester, I'd want to know what I am supposed to be > doing differently and not mark something +1 by mistake. I think this > concern goes away in the unicorn filled world wher

Re: [Guidelines Change] Changes to the Packaging Guidelines

On Fri, Dec 10, 2010 at 10:30 AM, Tom Callaway wrote: > On 12/10/2010 01:03 AM, Orcan Ogetbil wrote: >> rpmbuild can call either chmod -x on the %doc files at the end; or if >> the problem is just the dependencies added by executable %doc files, >> then rpmbuild can be taught to not scan the %doc

Re: [Guidelines Change] Changes to the Packaging Guidelines

Mamoru Tasaka wrote: > So, when a package > - contains some example scripts > - the packager thinks that such scripts are useful and many people actually > want to execute them > - but such scripts need additional dependencies > then the packager actually may want to add additional dependencies.

Re: Stomped by buildsys mail

-Xavier On 10 Dec 2010 21:32, "Michael J Gruber" wrote: > Got this: > > impressive has broken dependencies in the rawhide tree: > On x86_64: > impressive-0.10.3-3.el6.noarch requires pygame > On i386: > impressive-0.10.3-3.el6.noarch requires pygame > On ppc64: > impressive-0.10.3-3.el6.noarch req

[389-devel] Please Review: (588791) Allow anonymous rootDSE access only

https://bugzilla.redhat.com/show_bug.cgi?id=588791 https://bugzilla.redhat.com/attachment.cgi?id=468061&action=edit -- 389-devel mailing list 389-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel

Fedora Release Engineering meeting summary for 2010-12-10

Minutes:http://meetbot.fedoraproject.org/fedora- meeting/2010-12-10/fedora_releng.2010-12-10-20.01.html Minutes (text): http://meetbot.fedoraproject.org/fedora- meeting/2010-12-10/fedora_releng.2010-12-10-20.01.txt Log:http://meetbot.fedoraproject.org/fedora- meeting/2010-12-10

Re: Stomped by buildsys mail

On Friday, December 10, 2010 02:31:33 pm Michael J Gruber wrote: > Got this: > > impressive has broken dependencies in the rawhide tree: > On x86_64: > impressive-0.10.3-3.el6.noarch requires pygame > On i386: > impressive-0.10.3-3.el6.noarch requires pygame > On ppc64: > impress

[Bug 658453] "use JSON::RPC::Common::TypeConstraints" in perl script leads to error (fix inside)

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=658453 Fedora Update System changed: What|Removed |Added --

[Bug 658453] "use JSON::RPC::Common::TypeConstraints" in perl script leads to error (fix inside)

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=658453 --- Comment #4 from Fedora Update System 2010-12-10 15:30:44 EST --- perl-Moose-1.12-2.fc14 has been pushed to the Fedora 14 st

[Bug 624308] Package pre-dates the discovery of fire.

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=624308 --- Comment #9 from Fedora Update System 2010-12-10 15:31:03 EST --- perl-DBIx-Class-Schema-Loader-0.07002-2.fc14 has been push

[Bug 624308] Package pre-dates the discovery of fire.

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=624308 Fedora Update System changed: What|Removed |Added --

Stomped by buildsys mail

Got this: impressive has broken dependencies in the rawhide tree: On x86_64: impressive-0.10.3-3.el6.noarch requires pygame On i386: impressive-0.10.3-3.el6.noarch requires pygame On ppc64: impressive-0.10.3-3.el6.noarch requires pygame Please resolve this as soon as possib

Re: [Guidelines Change] Changes to the Packaging Guidelines

On Fri, Dec 10, 2010 at 7:15 PM, Mamoru Tasaka wrote: > Toshio Kuratomi wrote, at 12/11/2010 02:00 AM +9:00: >> On Fri, Dec 10, 2010 at 08:40:23PM +0900, Mamoru Tasaka wrote: >>> Thomas Moschny wrote, at 12/10/2010 08:19 PM +9:00: That seems by far the cleanest solution to me. Especially

Re: abrt wishlist

On 12/10/2010 04:27 PM, gia...@gmail.com wrote: > On Thu, Dec 9, 2010 at 5:20 PM, Jiri Moskovcak wrote: >> Gathering the RFEs at: https://fedorahosted.org/abrt/wiki/Wishlist >> > > Is it true report plugins are written in C++ ? if so, I'd love to RFE > "python wrapper to the plugins API" so we can

Re: [Guidelines] MUST: use ExcludeArch over ExclusiveArch

Alex Hudson wrote: > It doesn't make a lot of sense to me to ask Lubomir, the packager, to > change the current ExclusiveArch, because I think that is the more > correct expression of what this software supports. However, as a MUST: > requirement this is a review blocker. ExclusiveArch is a just

Re: [Guidelines] MUST: use ExcludeArch over ExclusiveArch

On 12/10/2010 02:00 PM, Alex Hudson wrote: > Obviously for expeditious reasons the change to the .spec could be made > to "dance the dance" as it were, but would I really get put on the > naughty step if I thought it should be approved as-is? No, this seems like a reasonable exception to me. ~tom

[Guidelines] MUST: use ExcludeArch over ExclusiveArch

Hi everyone, I have a small issue with the review of the v8 package that I'm currently looking at: https://bugzilla.redhat.com/show_bug.cgi?id=634909#c18 The short story is this; the packaging guidelines state that for every architecture a package doesn't build on, the .spec should list

Re: hosted reproducible package building with multiple developers?

2010/12/10 Matt McCutchen : > On Fri, 2010-12-10 at 15:06 +, Daniel P. Berrange wrote: >> Adding CLONE_NEWPID would be worthwhile to stop the >> mock process seeing any other PIDs on the machine. > > It's critical, or mock could ptrace some process running as root on the > host and inject arbit

Re: hosted reproducible package building with multiple developers?

On 12/10/2010 10:12 AM, Daniel P. Berrange wrote: > Oh fun, I didn't notice the permissions in /var/lib/mock/$NAME/root > were so open as to allow access from non-root users outside the > chroot. That could be locked down though, so that stuff inside the > chroot was only visible while on the insid

Re: [Guidelines Change] Changes to the Packaging Guidelines

Toshio Kuratomi wrote, at 12/11/2010 02:00 AM +9:00: > On Fri, Dec 10, 2010 at 08:40:23PM +0900, Mamoru Tasaka wrote: >> Thomas Moschny wrote, at 12/10/2010 08:19 PM +9:00: >>> That seems by far the cleanest solution to me. Especially >>> development-oriented packages often contain example director

Re: hosted reproducible package building with multiple developers?

On Fri, Dec 10, 2010 at 01:01:56PM -0500, James Ralston wrote: > On 2010-12-10 at 14:02+00 Daniel P Berrange wrote: > > > I'm not familiar with what attacks you can do on mocks' chroot setup > > offhand > > describes an easy one: > > $ /usr/bin/mock

Re: hosted reproducible package building with multiple developers?

On Fri, Dec 10, 2010 at 06:06:47PM +, Richard W.M. Jones wrote: > On Fri, Dec 10, 2010 at 03:06:59PM +, Daniel P. Berrange wrote: > > The theory is as follows though > > > > 1. clone() with the CLONE_NEWNS set > [...] > > There are various other CLONE flags that lock down more > > things

Re: hosted reproducible package building with multiple developers?

On Fri, Dec 10, 2010 at 03:06:59PM +, Daniel P. Berrange wrote: > The theory is as follows though > > 1. clone() with the CLONE_NEWNS set [...] > There are various other CLONE flags that lock down more > things if desired, eg to hide all host network interfaces. I don't think CLONE_* can sto

Re: hosted reproducible package building with multiple developers?

On 2010-12-10 at 14:02+00 Daniel P Berrange wrote: > I'm not familiar with what attacks you can do on mocks' chroot setup > offhand describes an easy one: $ /usr/bin/mock --init -r fedora-10-i386 $ /usr/bin/mock --shell -r fedora-10-i386 mock-chroot

Re: hosted reproducible package building with multiple developers?

On Fri, Dec 10, 2010 at 12:43:04PM -0500, Matt McCutchen wrote: > On Fri, 2010-12-10 at 15:06 +, Daniel P. Berrange wrote: > > Adding CLONE_NEWPID would be worthwhile to stop the > > mock process seeing any other PIDs on the machine. > > It's critical, or mock could ptrace some process running

Re: hosted reproducible package building with multiple developers?

On Fri, 2010-12-10 at 15:06 +, Daniel P. Berrange wrote: > Adding CLONE_NEWPID would be worthwhile to stop the > mock process seeing any other PIDs on the machine. It's critical, or mock could ptrace some process running as root on the host and inject arbitrary code. -- Matt -- devel maili

Re: hosted reproducible package building with multiple developers?

On 2010-12-08 at 21:00+00 "Richard W.M. Jones" wrote: > To the original poster: even a VM isn't a completely robust way of > preventing root escalations. This is a certainly true. If an attacker manages to gain control of a VM guest, he can attempt to attack the VM host. (In fact, depending on

[perl-Test-Exception] Update to 0.31.

commit 47e224a3357bb26417d7dc3388db65fe9b490152 Author: Steven Pritchard Date: Fri Dec 10 11:23:22 2010 -0600 Update to 0.31. .gitignore |1 + perl-Test-Exception.spec |7 +-- sources |2 +- 3 files changed, 7 insertions(+), 3 deletions(-) --

Re: [Guidelines Change] Changes to the Packaging Guidelines

On Fri, 10 Dec 2010, Toshio Kuratomi wrote: > On Fri, Dec 10, 2010 at 08:40:23PM +0900, Mamoru Tasaka wrote: >> Thomas Moschny wrote, at 12/10/2010 08:19 PM +9:00: >>> That seems by far the cleanest solution to me. Especially >>> development-oriented packages often contain example directories; >>>

File Test-Exception-0.31.tar.gz uploaded to lookaside cache by steve

A file has been added to the lookaside cache for perl-Test-Exception: adb57ca7614d15e5b307bf5e024b35a8 Test-Exception-0.31.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

Re: [Guidelines Change] Changes to the Packaging Guidelines

On 12/10/2010 06:00 PM, Toshio Kuratomi wrote: > On Fri, Dec 10, 2010 at 08:40:23PM +0900, Mamoru Tasaka wrote: >> Thomas Moschny wrote, at 12/10/2010 08:19 PM +9:00: >>> That seems by far the cleanest solution to me. Especially >>> development-oriented packages often contain example directories; >

Re: [Guidelines Change] Changes to the Packaging Guidelines

On Fri, Dec 10, 2010 at 08:40:23PM +0900, Mamoru Tasaka wrote: > Thomas Moschny wrote, at 12/10/2010 08:19 PM +9:00: > > That seems by far the cleanest solution to me. Especially > > development-oriented packages often contain example directories; > > removing x-bits there only puts extra-burden on

Re: [Guidelines Change] Changes to the Packaging Guidelines

On 12/10/2010 01:03 AM, Orcan Ogetbil wrote: > rpmbuild can call either chmod -x on the %doc files at the end; or if > the problem is just the dependencies added by executable %doc files, > then rpmbuild can be taught to not scan the %doc files for generating > dependencies. If no, why not? While

Re: abrt wishlist

On Thu, Dec 9, 2010 at 5:20 PM, Jiri Moskovcak wrote: > Gathering the RFEs at: https://fedorahosted.org/abrt/wiki/Wishlist > Is it true report plugins are written in C++ ? if so, I'd love to RFE "python wrapper to the plugins API" so we can write plugins more easily -- Gianluca Sforna http://

Re: hosted reproducible package building with multiple developers?

On Fri, Dec 10, 2010 at 09:17:27AM -0500, seth vidal wrote: > On Fri, 2010-12-10 at 14:02 +, Daniel P. Berrange wrote: > > On Wed, Dec 08, 2010 at 01:07:32PM -0500, seth vidal wrote: > > > On Wed, 2010-12-08 at 13:03 -0500, James Ralston wrote: > > > > Riddle me this. > > > > > > > > We want t

Re: abrt wishlist

> "Jan" == Jan Kratochvil writes: Jan> GDB on client side would need something like readonly NFS-like Jan> service to load the .debug files byte-wise. And this NFS-like Jan> service network protocol must be signed by Fedora project like the Jan> current rpms are. Jan> Then the fast operatio

Re: hosted reproducible package building with multiple developers?

On Fri, 2010-12-10 at 14:02 +, Daniel P. Berrange wrote: > On Wed, Dec 08, 2010 at 01:07:32PM -0500, seth vidal wrote: > > On Wed, 2010-12-08 at 13:03 -0500, James Ralston wrote: > > > Riddle me this. > > > > > > We want to provide a server for developers within our organization to > > > build

Re: hosted reproducible package building with multiple developers?

On Wed, Dec 08, 2010 at 01:07:32PM -0500, seth vidal wrote: > On Wed, 2010-12-08 at 13:03 -0500, James Ralston wrote: > > Riddle me this. > > > > We want to provide a server for developers within our organization to > > build RPM packages for use within our organization. > > > > These are our req

Re: hosted reproducible package building with multiple developers?

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12/08/2010 01:03 PM, James Ralston wrote: > Riddle me this. > > We want to provide a server for developers within our organization to > build RPM packages for use within our organization. > > These are our requirements: > > 1. The developers

Re: Firewall

On 12/10/2010 04:00 AM, Curtis Doty wrote: > Yesterday Miloslav Trma said: > >> Curtis Doty píÿÿe v St 08. 12. 2010 v 01:02 -0800: >>> Monday Miloslav Trma said: >>> Just disable the firewall and you'll get pretty much equivalent functionality. >>> >>> How? Now that the filter table and s

Re: [Guidelines Change] Changes to the Packaging Guidelines

On 12/10/2010 12:19 PM, Thomas Moschny wrote: > 2010/12/10 Orcan Ogetbil: >> [...] > On a related note, rpmlint also warns Warnings aren't errors ... in many cases, empty files are an indication of something having gone wrong somewhere, a package doing something improperly or a packager doing so

rawhide report: 20101210 changes

Compose started at Fri Dec 10 08:15:05 UTC 2010 Broken deps for x86_64 -- beagle-0.3.9-19.fc14.x86_64 requires libmono.so.0()(64bit) beagle-0.3.9-19.fc14.x86_64 requires libmono.so.0(VER_1)(64bit) cpm-0.23-0.3.beta.fc1

Re: [Guidelines Change] Changes to the Packaging Guidelines

Thomas Moschny wrote, at 12/10/2010 08:19 PM +9:00: > That seems by far the cleanest solution to me. Especially > development-oriented packages often contain example directories; > removing x-bits there only puts extra-burden on someone trying to play > with the examples. Indeed some examples/ dir

Re: [Guidelines Change] Changes to the Packaging Guidelines

2010/12/10 Orcan Ogetbil : > [...] > the problem is just the dependencies added by executable %doc files, > then rpmbuild can be taught to not scan the %doc files for generating > dependencies. That seems by far the cleanest solution to me. Especially development-oriented packages often contain ex

Re: abrt wishlist

On Thu, 2010-12-09 at 17:20 +0100, Jiri Moskovcak wrote: > > 4) Reporting to bugzilla without being able to scrape the bz username > > and password out of the firefox credential store is just cruel. > > > > - added as: "share bz credential with other apps" > - not sure if we can share the credent

Re: abrt wishlist

On 12/10/2010 09:24 AM, Michal Hlavinka wrote: > Adding my whishlist > > 1) /etc/abrt/conf.d/ directory - like httpd ones. So I can drop there > configuration for my packages. For example when dovecot crashes, I'd like to > see doveconf -n output - I can promise the /etc/abrt/conf.d/ only for bl

Re: ABRT opt-out (was Re: Summary/Minutes from today's FESCo meeting)

Hi, On Thu, Dec 9, 2010 at 7:57 PM, Adam Williamson wrote: > > if it just invisibly doesn't run, I'd try it again, but if I'm running > it from the console and it spits out a clear fatal error and crashes, > yeah, I'm not going to run it again. That'd be pointless. I would hope that most people

Re: ABRT opt-out (was Re: Summary/Minutes from today's FESCo meeting)

On 12/09/2010 08:57 PM, Kevin Fenzi wrote: > On Thu, 09 Dec 2010 14:53:20 -0500 > Przemek Klosowski wrote: > >> On 12/09/2010 12:05 PM, Adam Williamson wrote: >>> On Thu, 2010-12-09 at 12:08 +, "Jóhann B. Guðmundsson" wrote: On 12/09/2010 09:59 AM, Jiri Moskovcak wrote: > Just a wild

Re: ABRT opt-out (was Re: Summary/Minutes from today's FESCo meeting)

On 12/09/2010 08:57 PM, Adam Williamson wrote: > On Thu, 2010-12-09 at 14:53 -0500, Przemek Klosowski wrote: >> On 12/09/2010 12:05 PM, Adam Williamson wrote: >>> On Thu, 2010-12-09 at 12:08 +, "Jóhann B. Guðmundsson" wrote: On 12/09/2010 09:59 AM, Jiri Moskovcak wrote: > Just a wild i

Re: abrt wishlist

Adding my whishlist 1) /etc/abrt/conf.d/ directory - like httpd ones. So I can drop there configuration for my packages. For example when dovecot crashes, I'd like to see doveconf -n output 2) better notification for crashes. I have one application that crashes when I'm ending desktop session,