Re: noexec on /dev/shm

2010-12-14 Thread Lennart Poettering
On Tue, 14.12.10 22:19, John Reiser (jrei...@bitwagon.com) wrote:

> Also, the claim "The API for /dev/shm is shm_open()" is incorrect.
> See the other message for the history.  When something is in the file
> system, then by default the file system APIs (including creat, open,
> read, write, close, execve, dlopen, ...) are legitimate uses.
> (Originally [System V] shared memory was *not* in the file system,
> and this caused problems.)

Don't conflate SysV and POSIX shared memory. They are completely
orthogonal. SysV shared memory does not appear in /dev/shm.

Lennart

-- 
Lennart Poettering - Red Hat, Inc.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel


Re: noexec on /dev/shm

2010-12-14 Thread Lennart Poettering
On Tue, 14.12.10 18:22, Miloslav Trmač (m...@volny.cz) wrote:

> Bill Nottingham píše v Út 14. 12. 2010 v 12:08 -0500:
> > > The problem is not the technical solution. Problem is that changes of
> > > such important thing like /etc/fstab are decided without Fedora 
> > > developers.
> > 
> > Eh, what? It's a change to how API filesystems (/proc, /sys, etc.) get
> > mounted. When this was done in rc.sysinit, every change to how it mounted
> > /proc wasn't discussed on the devel list. When we switched to having dracut
> > be the primary way that API filesystems are mounted, that wasn't put up
> > to a FESCo vote. 
> The practical difference is that nothing broke at that time, whereas
> systemd tends to break thinks that users use. (I won't buy dismissing it
> as "mere bugs" - adding NOEXEC could hardly have been a typo.)
>   Mirek
> 

"tends to break"? On what is that founded? Have you filed bugs?

Lennart

-- 
Lennart Poettering - Red Hat, Inc.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: noexec on /dev/shm

2010-12-14 Thread Lennart Poettering
On Tue, 14.12.10 14:25, Richard W.M. Jones (rjo...@redhat.com) wrote:

> 
> On Tue, Dec 14, 2010 at 02:24:53PM +0100, Tomasz Torcz wrote:
> >   We saw it includes /dev, /dev/shm etc.  Is there any *reasonable* need
> > to mount sysfs somewhere else than /sys. Or /dev with mode other than 755?
> > Those all directories are mounted _identically_ on every Linux distribution
> > down here.  Why pollute fstab with repeated lines on million machines?
> 
> The issue here isn't that the reporter wanted to mount them somewhere
> else, but he wanted to set the default mount options to something else
> (or in fact to set them back to how they are now -- systemd has
> decided to use some other mount options entirely without consulting
> anyone else).

Jeez. Tha's just FUD. Of course we have discussed this openly with
various folks. We haven't discussed this with you, Rich, personally, but
well, I'll make a note now tht I'll DoS you now with every single
choice we make, to get your blessing.

Lennart

-- 
Lennart Poettering - Red Hat, Inc.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel


Re: noexec on /dev/shm

2010-12-14 Thread John Reiser
On 12/14/2010 09:37 PM, Lennart Poettering wrote:
> On Sun, 12.12.10 19:49, John Reiser (jrei...@bitwagon.com) wrote:
> 
>> The project is a database system that creates and dlopen()s
>> plugins on-the-fly, for better performance on ["long-running"] queries.
>> We like the speed of creat+write+close+open+read+mmap on /dev/shm.
>> If /dev/shm and /tmp both become off limits, then what is
>> the recommended replacement location?
> 
> The API for /dev/shm is shm_open(). Unless you are using that API you
> shouldn't really touch /dev/shm.
> 
> What's wrong with /tmp for your use cases?

As I wrote another place under this topic (at
http://lists.fedoraproject.org/pipermail/devel/2010-December/147159.html
which crossed in the posting mail), some applications prefer to avoid /tmp
for such purposes because /tmp often is too slow: a real harddrive (needs
capacity larger than RAM) with a heavy-weight file system (to provide
full-featured ACLs, etc.) which often suffers contention.

Also, the claim "The API for /dev/shm is shm_open()" is incorrect.
See the other message for the history.  When something is in the file
system, then by default the file system APIs (including creat, open,
read, write, close, execve, dlopen, ...) are legitimate uses.
(Originally [System V] shared memory was *not* in the file system,
and this caused problems.)

-- 
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel


Re: noexec on /dev/shm

2010-12-14 Thread Lennart Poettering
On Tue, 14.12.10 17:54, Paul Wouters (p...@xelerance.com) wrote:

> On Tue, 14 Dec 2010, Tomasz Torcz wrote:
> 
> >  Of course administrator can temporary override:
> > mount /dev/shm -o remount, nosuid
> >
> > Or even have it stick after reboot, by droping in /etc/systemd/system/
> > following unit definition¹:
> 
> No.
> 
> You either follow what is in /etc/fstab, or you disallow it from /etc/fstab.
> 
> You do not ignore /etc/fstab.
> 
> And if for some bad reason you do decided to ignore /etc/fstab, this should
> clearly cause log entries, and there should be a clear man page section for
> the man page in "man fstab" explaining this.
> 
> Yes, documentation is not sexy. No source code is not documentation

systemd documentation is actually pretty good and mostly
comprehensive. Humble as I am I would even say that it is vastly
superior to the majority of all open source projects. If you want to
criticise us on something, pick something else, please.

Yes, reading documentation is not sexy, but just bitching isn't reading
documentation.

Lennart

-- 
Lennart Poettering - Red Hat, Inc.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel


Re: noexec on /dev/shm

2010-12-14 Thread Lennart Poettering
On Tue, 14.12.10 08:08, Chris Adams (cmad...@hiwaay.net) wrote:

> 
> Once upon a time, Tomasz Torcz  said:
> >   We saw it includes /dev, /dev/shm etc.  Is there any *reasonable* need
> > to mount sysfs somewhere else than /sys. Or /dev with mode other than 755?
> > Those all directories are mounted _identically_ on every Linux distribution
> > down here.  Why pollute fstab with repeated lines on million machines?
> 
> What is the advantage to making some mounts not listed in the file with
> all the other mounts?  It isn't like /etc/fstab is a hundred lines or
> anything; it is a standard config file that predates Linux.  All mounts
> are listed there until systemd decided to override it (without any
> warning or documentation).

Well, what would be the advantage of listing it? Confusing the admin
with lines that are an implementation detail of the OS? Or giving the
admin the suggestion to maybe change the mount point of procfs to /waldo
and see how everyting breaks?

Also, the list in /etc/fstab never was complete anyway. It never listed
/selinux, neither /sys/fs/cgroup (or its predecessor /cgroup), or
/sys/kernel/security, or /dev/hugepages, or /dev/mqueue, or binfmt_misc,
or /sys/kernel/debug, or the rpc_pipefs, or the fuse connections fs.

(Also, this discussion is premature anyway, since I have not asked the
Anaconda team to drop the default procfs/sysfs lines from fstab, and
won't do so before F16).

Lennart

-- 
Lennart Poettering - Red Hat, Inc.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel


Re: noexec on /dev/shm

2010-12-14 Thread Lennart Poettering
On Tue, 14.12.10 13:53, Miloslav Trmač (m...@volny.cz) wrote:

> Changing the semantics of /etc/fstab without any consultation with
> fedora-devel or even notification of Fedora that something so
> long-standing is changing is hardly constructive either.
> 
> I can happily live with "systemd is a new, better init system" without
> knowing the details.  I consider "systemd replaces 15% of /etc and
> changes semantics of another 5%" without discussing the details in
> advance unacceptable for the distribution as a whole, although this
> decision is of course FESCo's.

All these things are actually discussed very much on IRC, and systemd
upstream mailing lists and similar places. Quite a few people from
various distirbutions have been involved and whenever we feel it really
is necessary to inroduce a configuration file for something we don't
take this decision lightly, and involve a lot of people so that we come
to a soltuion that people from all distributions can live with. Also, in
every case where we actually introduced a new configuration file we
carefully made sure to provide compatibility to the previous
per-distribution configuration files. For example: every distro placed
system-wide locale settings in a different configuration files. After
doing a survey we felt that it was most appropriate to unify this in a
new configuration file /etc/locale.conf instead of declaring any of the
existing solutions the new standard for systemd-based systems. However,
if systemd is built on Fedora we actually do fall back to
/etc/sysconfig/i18n, to provide a sane upgrade path.

I guess what I want to say is that all of this is openly discussed
with input from a lot of people. Yes, we don't have discussed this on
fedora-devel, but a) I am pretty sure that the subscribers of this ML
wouldn't like the amount of traffic this would generate and b) this is
not really fedora-specific, but something to discuss with other distros
too, and c) I haven't really experienced fedora-devel as a great place
to discuss technical things with constructive input, but mostly as a
place where people (not all, but definitely too many) are
"negative-by-default" and like implying that we
1) want to destroy Unix/Linux, 2) are idiots or 3) would decide
everything behind closed doors.

Or, to turn this around: if you want to have a say, if you want to
influence systemd's design, then join devlopment upstream, or otherwise
become involved. Just standing on the sidelines and expecting that we
will ask you personally for your kind comments, is not going to happen.

The duty to involve yourself is on you!

Lennart

-- 
Lennart Poettering - Red Hat, Inc.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: noexec on /dev/shm

2010-12-14 Thread John Reiser
On 12/14/2010 07:28 PM, Lennart Poettering wrote:

> In order to make things secure we minimize what is allowd on the various
> API file systems we mount. That includes that we set noexec and similar
> options for the file systems involved. The interface how to access
> /dev/shm is called shm_open(), and given that this is how it is there is
> very little reason to allow people to execute binaries from them. Of
> course, this is a very recent change, and at this point while we assume
> that this will not break any valid use of this directory, we cannot be
> sure about this, so we'd be very interested to learn why exactly you
> want the noexec to be dropped. What is your application that needs that?
> If there is a point in dropping the noexec, we'll definitely be willing
> to do so, but if the only reason would be "I always misused /dev/shm as
> a scratch space", then we won't be very convinced. The API fom /dev/shm
> is shm_open(), and if you place other stuff in there, then you are
> misusing it and actually creating all kinds of namespacing problems
> (since /dev/shm is actually an all-user shared namespace), and we aren't
> particularly keen to support such misuses by default.

The claim "The API for /dev/shm is shm_open()" is incorrect.
Very early in the history of shm [late 1970's at the Columbus, Ohio, USA
branch of Bell Telephone Laboratories], then shm_open, shmget, etc., were
the only means of access; the objects had names that were 32-bit binary
integers.  In fact, when shm became more widely used then there were
denial-of-service attacks based on the premise that enumerating objects
in shm required 2**32 exhaustive search via shmget.  As soon as /dev/shm
was integrated into the filesystem, then creat, open, read, write, close,
lseek, execve, etc. (any filesystem API) became additional access paths.
This integration began appearing by about the mid 1980's, around 25 years
ago, and since then applications have been using /dev/shm via ordinary
files system APIs in addition to shmget etc.

Why?  Because *fast* operations on small numbers of small-to-medium-sized
files can be a big advantage for performance.  /tmp often is much slower
because /tmp often is a harddrive: the need for space in /tmp often exceeds
the size of physical RAM.  Also, mounting /tmp as tmpfs can meet resistance
because tmpfs does not support all features that applications expect.
A ramdisk might be used, except that early ramdisks allowed at most a few
megabytes (comparable to the capacity of a floppy disk), which is not
large enough to support typical simultaneous usage.  Applications
also cannot rely on ramdisks because superuser privileges usually are
required to access a ramdisk.  In many cases ramdisks have been replaced
by:  /dev/shm !!

I have applications which use /dev/shm via file system APIs, including
execve() and dlopen().  Both of those fail when /dev/shm has MS_NOEXEC.
One group of applications generates database plugins on-the-fly in a
just-in-time fashion.  Of course non-interactive performance increases
in the usual way that substituting compiled code for interpreted often
gives a speedup of 8X or more.  Interactive response also improves, because
small files in /dev/shm do not contend with operations in /tmp which
can require slow sync() or large transfers.  In some cases even /dev/shm
is slower than desirable.  I have requested dlopen() from memory:
   http://sourceware.org/bugzilla/show_bug.cgi?id=11767 .
Meanwhile, /dev/shm is the only choice which is present always
and sufficiently fast.

It is just not true that file system APIs are a misuse of /dev/shm.

-- 
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel


Re: noexec on /dev/shm

2010-12-14 Thread Lennart Poettering
On Sun, 12.12.10 19:49, John Reiser (jrei...@bitwagon.com) wrote:

> The project is a database system that creates and dlopen()s
> plugins on-the-fly, for better performance on ["long-running"] queries.
> We like the speed of creat+write+close+open+read+mmap on /dev/shm.
> If /dev/shm and /tmp both become off limits, then what is
> the recommended replacement location?

The API for /dev/shm is shm_open(). Unless you are using that API you
shouldn't really touch /dev/shm.

What's wrong with /tmp for your use cases?

Lennart

-- 
Lennart Poettering - Red Hat, Inc.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel


Re: noexec on /dev/shm

2010-12-14 Thread Nicholas Miell
On 12/14/2010 07:28 PM, Lennart Poettering wrote:
> In order to make things secure we minimize what is allowd on the various
> API file systems we mount. That includes that we set noexec and similar
> options for the file systems involved. The interface how to access
> /dev/shm is called shm_open(), and given that this is how it is there is
> very little reason to allow people to execute binaries from them. Of
> course, this is a very recent change, and at this point while we assume
> that this will not break any valid use of this directory, we cannot be
> sure about this, so we'd be very interested to learn why exactly you
> want the noexec to be dropped. What is your application that needs that?
> If there is a point in dropping the noexec, we'll definitely be willing
> to do so, but if the only reason would be "I always misused /dev/shm as
> a scratch space", then we won't be very convinced. The API fom /dev/shm
> is shm_open(), and if you place other stuff in there, then you are
> misusing it and actually creating all kinds of namespacing problems
> (since /dev/shm is actually an all-user shared namespace), and we aren't
> particularly keen to support such misuses by default.
> 

shm_open() takes the standard mode flags, and mmap() with PROT_EXEC on a
+x fd returned by shm_open() is a legitimate operation that is required
by POSIX.

This is a perfectly reasonable thing to do on a SELinux-enabled system
which requires e.g. a JIT to write generated code to the writable
mapping and execute that code from the executable mapping of the same
shared memory object.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel


Re: noexec on /dev/shm

2010-12-14 Thread Garrett Holmstrom
On 12/14/2010 21:28, Lennart Poettering wrote:
> On Tue, 14.12.10 12:08, Bill Nottingham (nott...@redhat.com) wrote:
>
> Thanks, Bill, for replying in so much detail.
>
> Here are a few other points:
>
>> - systemd mounts API filesystems without them needing to be in
>>/etc/fstab. This is for a variety of reasons - having every system
>>installer have to write /proc, /sys, and so on is pretty wasteful. It
>>also can give inexperienced admins the idea that it's configuration
>>that can be changed - they then rename the mount point from /proc
>>to /processes and *kaboom*.
>
> The main reason we mount /sys and /proc and friends in C code this early
> is that we simply need them ourselves. To do what systemd does, it must
> be able to rely that it can read process data from /proc, or device
> information from /sys, or cgroup information from /sys/fs/cgroup.
>
> There is simply no way around this, and just to make a point, Upstart
> mounts some of those FS too, in C code (however not /dev/shm), there's
> very little effective difference here, and if people whine and say
> "things have never een done this way, you a are breaking UNIX", then I
> can only reply, that that's simply wrong.
>
> Having said all this I actually believe that there is very little point
> in listing "API" file systems like these in /etc/fstab. They are after
> all API, hence only relevant for application code, not really useful for
> direct interaction or even reconfiguation by the user. Or in other
> words: While it definitely makes sense to ount /dev/sda5 to whatever
> mount point the user chooses, the mount point and options for the API
> file systems are pretty much an implementation detail for the OS, and
> there should never be a need to change them.
>
> In order to make things secure we minimize what is allowd on the various
> API file systems we mount. That includes that we set noexec and similar
> options for the file systems involved. The interface how to access
> /dev/shm is called shm_open(), and given that this is how it is there is
> very little reason to allow people to execute binaries from them. Of
> course, this is a very recent change, and at this point while we assume
> that this will not break any valid use of this directory, we cannot be
> sure about this, so we'd be very interested to learn why exactly you
> want the noexec to be dropped. What is your application that needs that?
> If there is a point in dropping the noexec, we'll definitely be willing
> to do so, but if the only reason would be "I always misused /dev/shm as
> a scratch space", then we won't be very convinced. The API fom /dev/shm
> is shm_open(), and if you place other stuff in there, then you are
> misusing it and actually creating all kinds of namespacing problems
> (since /dev/shm is actually an all-user shared namespace), and we aren't
> particularly keen to support such misuses by default.
>
> That said, because we anticipated that there are some valid uses to
> change the settings of these mount points (e.g. change size= for tmpfs)
> we actually do apply the options from /etc/fstab, if the file system is
> listed there. So if you really really want to misuse /dev/shm, you
> may. Apparently this particular feature was broken (see Bill's comments),
> and hence please file a bug about this.

I'm fine with that as long as it is documented, particularly in the 
fstab man page and as commentary in /etc/fstab on newly-installed 
systems so people who read it and notice missing filesystems don't 
panic.  Thanks for explaining your thought process.

It sounds like /tmp would be a better location to remove noexec from 
than /dev/shm if one needs memory-backed storage for things and doesn't 
want to create a new filesystem for that purpose.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel


Re: noexec on /dev/shm

2010-12-14 Thread Lennart Poettering
On Tue, 14.12.10 12:08, Bill Nottingham (nott...@redhat.com) wrote:

Thanks, Bill, for replying in so much detail.

Here are a few other points:

> - systemd mounts API filesystems without them needing to be in
>   /etc/fstab. This is for a variety of reasons - having every system
>   installer have to write /proc, /sys, and so on is pretty wasteful. It
>   also can give inexperienced admins the idea that it's configuration
>   that can be changed - they then rename the mount point from /proc
>   to /processes and *kaboom*.

The main reason we mount /sys and /proc and friends in C code this early
is that we simply need them ourselves. To do what systemd does, it must
be able to rely that it can read process data from /proc, or device
information from /sys, or cgroup information from /sys/fs/cgroup. 

There is simply no way around this, and just to make a point, Upstart
mounts some of those FS too, in C code (however not /dev/shm), there's
very little effective difference here, and if people whine and say
"things have never een done this way, you a are breaking UNIX", then I
can only reply, that that's simply wrong.

Having said all this I actually believe that there is very little point
in listing "API" file systems like these in /etc/fstab. They are after
all API, hence only relevant for application code, not really useful for
direct interaction or even reconfiguation by the user. Or in other
words: While it definitely makes sense to ount /dev/sda5 to whatever
mount point the user chooses, the mount point and options for the API
file systems are pretty much an implementation detail for the OS, and
there should never be a need to change them. 

In order to make things secure we minimize what is allowd on the various
API file systems we mount. That includes that we set noexec and similar
options for the file systems involved. The interface how to access
/dev/shm is called shm_open(), and given that this is how it is there is
very little reason to allow people to execute binaries from them. Of
course, this is a very recent change, and at this point while we assume
that this will not break any valid use of this directory, we cannot be
sure about this, so we'd be very interested to learn why exactly you
want the noexec to be dropped. What is your application that needs that?
If there is a point in dropping the noexec, we'll definitely be willing
to do so, but if the only reason would be "I always misused /dev/shm as
a scratch space", then we won't be very convinced. The API fom /dev/shm
is shm_open(), and if you place other stuff in there, then you are
misusing it and actually creating all kinds of namespacing problems
(since /dev/shm is actually an all-user shared namespace), and we aren't
particularly keen to support such misuses by default.

That said, because we anticipated that there are some valid uses to
change the settings of these mount points (e.g. change size= for tmpfs)
we actually do apply the options from /etc/fstab, if the file system is
listed there. So if you really really want to misuse /dev/shm, you
may. Apparently this particular feature was broken (see Bill's comments),
and hence please file a bug about this.

So, in the long run, I believe /etc/fstab should only list real disk and
network file systems, and all the API file systems should not be visible
there. The list of API file systems mounted and the list of API file
systems configured in this file usually has been differing anyway, and
hence I would simply not list them by default there anymore at all. You
could even say that this brings /etc/fstab back to its traditional
roots, since the glut of virtual API file systems is actually a very
recent change in history, and for the longest time /proc was really the
only one ever used. So, Unix-Lovers, please say "thank you", we are
bringing back to you a piece of good old Unix/Linux, that has long been
taken away from you, by evil Unix-haters!

[ and again, "not listing by default" by no means means that you couldnt
list them there if you wanted to to or that your options would be ignored
by design -- as soon as the aforementioned bug is fixed ]

(Sorry for no responding more timely. i have been (and still am)
backpacking through India, and my access to the Internet has been only
sporadic and slow)

Lennart

-- 
Lennart Poettering - Red Hat, Inc.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel


Re: noexec on /dev/shm

2010-12-14 Thread Adam Williamson
On Tue, 2010-12-14 at 17:54 -0500, Paul Wouters wrote:
> On Tue, 14 Dec 2010, Tomasz Torcz wrote:
> 
> >  Of course administrator can temporary override:
> > mount /dev/shm -o remount, nosuid
> >
> > Or even have it stick after reboot, by droping in /etc/systemd/system/
> > following unit definition¹:
> 
> No.
> 
> You either follow what is in /etc/fstab, or you disallow it from /etc/fstab.
> 
> You do not ignore /etc/fstab.

You appear to have missed the bit where Bill explained, twice, that
systemd is not actually designed to ignore /etc/fstab, and this is just
a bug.
-- 
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: noexec on /dev/shm

2010-12-14 Thread Paul Wouters
On Tue, 14 Dec 2010, Bill Nottingham wrote:

> It probably should be relnoted, sure.

A relnote is not a substitute for proper documentation, logging and man pages.

Paul
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel


Re: noexec on /dev/shm

2010-12-14 Thread Paul Wouters
On Tue, 14 Dec 2010, Tomasz Torcz wrote:

>  Of course administrator can temporary override:
> mount /dev/shm -o remount, nosuid
>
> Or even have it stick after reboot, by droping in /etc/systemd/system/
> following unit definition¹:

No.

You either follow what is in /etc/fstab, or you disallow it from /etc/fstab.

You do not ignore /etc/fstab.

And if for some bad reason you do decided to ignore /etc/fstab, this should
clearly cause log entries, and there should be a clear man page section for
the man page in "man fstab" explaining this.

Yes, documentation is not sexy. No source code is not documentation

Paul (yes, bitter by the horrors of 10 years of iproute2)
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: noexec on /dev/shm

2010-12-14 Thread Tomasz Torcz
On Tue, Dec 14, 2010 at 02:25:38PM +, Richard W.M. Jones wrote:
> On Tue, Dec 14, 2010 at 02:24:53PM +0100, Tomasz Torcz wrote:
> >   We saw it includes /dev, /dev/shm etc.  Is there any *reasonable* need
> > to mount sysfs somewhere else than /sys. Or /dev with mode other than 755?
> > Those all directories are mounted _identically_ on every Linux distribution
> > down here.  Why pollute fstab with repeated lines on million machines?
> 
> The issue here isn't that the reporter wanted to mount them somewhere
> else, but he wanted to set the default mount options to something else
> (or in fact to set them back to how they are now -- systemd has
> decided to use some other mount options entirely without consulting
> anyone else).
> 
> I think it's very reasonable to want to edit /etc/fstab to change the
> default mount options of these filesystems.  Suppose that /dev/shm
> defaults to allowing suid and exec.  At some point in the future a
> security problem is found which can be worked around by temporarily
> setting nosuid on /dev/shm (while the real issue is fixed).  An
> administrator can't do that without recompiling systemd.

  Of course administrator can temporary override:
mount /dev/shm -o remount, nosuid

Or even have it stick after reboot, by droping in /etc/systemd/system/
following unit definition¹:

--
[Unit]
Description=Temporary workaround for CVE-x
DefaultDependencies=false
WantedBy=local-fs.target

[Service]
ExecStart=/bin/mount /dev/shm -o remount, nosuid
Type=oneshot
--

  While I agree that hidden mounts are bad idea, they're
still visible in "systemctl -t mount" and "findmnt" output.

¹ created ad-hoc to show idea, not tested

-- 
Tomasz Torcz   RIP is irrevelant. Spoofing is futile.
xmpp: zdzich...@chrome.pl Your routes will be aggreggated. -- Alex Yuriev
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: noexec on /dev/shm

2010-12-14 Thread Adam Williamson
On Tue, 2010-12-14 at 13:48 -0500, Bill Nottingham wrote:

> And again, listing things like /sys in fstab can just give the
> uninitiated the idea that it's something they can change... it's *not*
> a configuration setting.

But I want to mount my /sys over nfs! What do you mean, it's not going
to work? Make it!
-- 
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


Plan for tomorrow's FESCo meeting (2010-12-15)

2010-12-14 Thread Kevin Fenzi
Following is the list of topics that will be discussed in the FESCo
meeting tomorrow at 17:30UTC (12:30pm EDT) in #fedora-meeting on
irc.freenode.net.

= Followups =

#508 improve the general standard of packagers/maintainers in the distribution.
https://fedorahosted.org/fesco/ticket/508

#515 Investigate a "features" repo for stable releases
https://fedorahosted.org/fesco/ticket/515

#516 Updates policy adjustments/changes
https://fedorahosted.org/fesco/ticket/516

#517 Updates Metrics
https://fedorahosted.org/fesco/ticket/517

= New business =

#518 Abrt
https://fedorahosted.org/fesco/ticket/518

#521 Reconsider RemoveSUID feature
https://fedorahosted.org/fesco/ticket/521

#522 F15Feature: GCC46 - http://fedoraproject.org/wiki/Features/GCC46
https://fedorahosted.org/fesco/ticket/522

#523 F15Feature: XenPvopsDom0 - 
http://fedoraproject.org/wiki/Features/XenPvopsDom0
https://fedorahosted.org/fesco/ticket/523

= Fedora Engineering Services tickets = 

https://fedorahosted.org/fedora-engineering-services/report/6

= Open Floor = 

For more complete details, please visit each individual ticket.  The
report of the agenda items can be found at
https://fedorahosted.org/fesco/report/9

If you would like to add something to this agenda, you can reply to
this e-mail, file a new ticket at https://fedorahosted.org/fesco,
e-mail me directly, or bring it up at the end of the meeting, during
the open floor topic. Note that added topics may be deferred until
the following meeting. 

kevin


signature.asc
Description: PGP signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: noexec on /dev/shm

2010-12-14 Thread Bill Nottingham
Miloslav Trmač (m...@volny.cz) said: 
> So the design was to
> 1) change the setting in the C reimplementation

The design was to pick a default... it's actually been that way since the
initial implementation and that *is* the default on some other distributions.

It probably should be relnoted, sure.

> 2) add a new facility that will revert the setting to its original value

No, the facility is intended to apply fstab settings to any early mounted
filesystem, including filesystems mounted in initramfs, etc. This is
actually something that didn't exist before - for example, in earlier
Fedora releases, for some filesystems you were stuck with whatever
options rc.sysinit or dracut mounted them with, regardless of what's
in /etc/fstab.

Bill
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Safest way to go from x86 to x86_64

2010-12-14 Thread seth vidal
On Tue, 2010-12-14 at 10:47 -0800, Philip Prindeville wrote:
> On 12/14/10 6:46 AM, Richard W.M. Jones wrote:
> > On Tue, Dec 14, 2010 at 02:35:24PM +, Paul Johnson wrote:
> >> Hi,
> >>
> >> On 14 December 2010 14:27, Richard W.M. Jones  wrote:
> >>
> >>> On Tue, Dec 14, 2010 at 02:07:37PM +, Paul Johnson wrote:
> >>>
>  Is there a safe way to install the x86_64 system over the 32 bit version
> >>> and
>  then clean off the 32 bit stuff that is no longer needed? If I was using
>  f14, I'd just trash the drive and then install, but I've got things how I
>  want them under rawhide.
> >>> Not really.  I would definitely suggest that you reinstall.
> >>>
> >>> I thought that would be the case - just wanted to check to ensure it's not
> >> something I can do another way.
> >>
> >> Okay, let's try another. Is there a way to grab a list of the packages
> >> installed and use a network installer to do the job based on the list?
> > I guess you can do:
> >
> > rpm -qa --qf '%{name}\n'>  kickstart
> >
> > and try to construct a kickstart file out of that ...
> >
> > Rich.
> >
> 
> Also, use "rpm -Va" to get a list of config files that have been modified.
> 
> Unfortunately, there's no way to detect additional files (in /etc, etc) that 
> aren't owned by a package but represent additional configuration state you 
> might want to bring over.
> 
> I usually make a copy of config files (cp -p $file $file.orig) before I edit 
> them the first time... then just do "locate .orig" to find them all.

Sure you can:

for file in `find /etc`
do 
 rpm -qf $file > /dev/null
 if [ $? != 0 ]; then
   echo $file unowned
 fi
done

-sv


-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel


Re: noexec on /dev/shm

2010-12-14 Thread Bill Nottingham
Chris Adams (cmad...@hiwaay.net) said: 
> I've seen this said at least a couple of times.  In what way is it
> "wasteful"?  On most systems, /etc/fstab is going to be less than one
> filesystem block anyway, so there is absolutely zero "waste" going on.
> 
> If "waste" of a few dozen bytes is now an issue, /etc/fstab is hardly
> the place to start.

The waste is the code in anaconda that's required to write this on
every install. Then, if new filesystems are added between releases, you
need to 1) patch anaconda 2) have truly gross %post scripts to edit /etc/fstab,
or 3) you write code that just hardcodes the mount anyway.

And again, listing things like /sys in fstab can just give the
uninitiated the idea that it's something they can change... it's *not*
a configuration setting.

Bill
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel


Re: Safest way to go from x86 to x86_64

2010-12-14 Thread Philip Prindeville
On 12/14/10 6:46 AM, Richard W.M. Jones wrote:
> On Tue, Dec 14, 2010 at 02:35:24PM +, Paul Johnson wrote:
>> Hi,
>>
>> On 14 December 2010 14:27, Richard W.M. Jones  wrote:
>>
>>> On Tue, Dec 14, 2010 at 02:07:37PM +, Paul Johnson wrote:
>>>
 Is there a safe way to install the x86_64 system over the 32 bit version
>>> and
 then clean off the 32 bit stuff that is no longer needed? If I was using
 f14, I'd just trash the drive and then install, but I've got things how I
 want them under rawhide.
>>> Not really.  I would definitely suggest that you reinstall.
>>>
>>> I thought that would be the case - just wanted to check to ensure it's not
>> something I can do another way.
>>
>> Okay, let's try another. Is there a way to grab a list of the packages
>> installed and use a network installer to do the job based on the list?
> I guess you can do:
>
> rpm -qa --qf '%{name}\n'>  kickstart
>
> and try to construct a kickstart file out of that ...
>
> Rich.
>

Also, use "rpm -Va" to get a list of config files that have been modified.

Unfortunately, there's no way to detect additional files (in /etc, etc) that 
aren't owned by a package but represent additional configuration state you 
might want to bring over.

I usually make a copy of config files (cp -p $file $file.orig) before I edit 
them the first time... then just do "locate .orig" to find them all.

-Philip


-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel


[perl-MLDBM] Update to 2.04. Fix find option order. Use fixperms macro instead of our own chmod incantation. Upda

2010-12-14 Thread Steven Pritchard
commit 6823491fc52c52cd1ff5e2257e46079e4428f37d
Author: Steven Pritchard 
Date:   Tue Dec 14 12:37:31 2010 -0600

Update to 2.04.
Fix find option order.
Use fixperms macro instead of our own chmod incantation.
Update Source0 URL.
Minor cosmetic changes to resemble cpanspec output.
BR Module::Build and build with that.
BR Test::More.

 .gitignore  |1 +
 perl-MLDBM.spec |   52 +++-
 sources |2 +-
 3 files changed, 29 insertions(+), 26 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index e688f60..efe2de9 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1 +1,2 @@
 MLDBM-2.01.tar.gz
+/MLDBM-2.04.tar.gz
diff --git a/perl-MLDBM.spec b/perl-MLDBM.spec
index 4dee830..149fd03 100644
--- a/perl-MLDBM.spec
+++ b/perl-MLDBM.spec
@@ -1,59 +1,61 @@
 Name:   perl-MLDBM
-Version:2.01
-Release:10%{?dist}
+Version:2.04
+Release:1%{?dist}
 Summary:Store multi-level hash structure in single level tied hash
-
-Group:  Development/Libraries
 License:GPL+ or Artistic
+Group:  Development/Libraries
 URL:http://search.cpan.org/dist/MLDBM/
-Source0:
http://www.cpan.org/authors/id/C/CH/CHAMAS/MLDBM-%{version}.tar.gz
+Source0:
http://www.cpan.org/authors/id/C/CH/CHORNY/MLDBM-%{version}.tar.gz
 BuildRoot:  %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
-
 BuildArch:  noarch
-BuildRequires:  perl(ExtUtils::MakeMaker)
 BuildRequires:  perl(FreezeThaw)
+BuildRequires:  perl(Module::Build)
+BuildRequires:  perl(Test::More)
 Requires:   perl(:MODULE_COMPAT_%(eval "`%{__perl} -V:version`"; echo 
$version))
 
 %description
-This module can serve as a transparent interface to any TIEHASH package that is
-required to store arbitrary perl data, including nested references.  Thus, this
-module can be used for storing references and other arbitrary data within DBM
-databases.
-
+This module can serve as a transparent interface to any TIEHASH package
+that is required to store arbitrary perl data, including nested references.
+Thus, this module can be used for storing references and other arbitrary
+data within DBM databases.
 
 %prep
 %setup -q -n MLDBM-%{version}
 
-
 %build
-%{__perl} Makefile.PL INSTALLDIRS=vendor
-make %{?_smp_mflags}
-
+%{__perl} Build.PL installdirs=vendor
+./Build
 
 %install
 rm -rf $RPM_BUILD_ROOT
-make pure_install PERL_INSTALL_ROOT=$RPM_BUILD_ROOT
-find $RPM_BUILD_ROOT -type f -name .packlist -exec rm -f {} ';'
-find $RPM_BUILD_ROOT -type d -depth -exec rmdir {} 2>/dev/null ';'
-chmod -R u+w $RPM_BUILD_ROOT/*
 
+./Build install destdir=$RPM_BUILD_ROOT create_packlist=0
+find $RPM_BUILD_ROOT -depth -type d -exec rmdir {} 2>/dev/null \;
 
-%check
-make test
+%{_fixperms} $RPM_BUILD_ROOT/*
 
+%check
+./Build test
 
 %clean
 rm -rf $RPM_BUILD_ROOT
 
-
 %files
 %defattr(-,root,root,-)
 %doc Changes README
 %{perl_vendorlib}/*
-%{_mandir}/man3/*.3pm*
-
+%{_mandir}/man3/*
 
 %changelog
+* Tue Dec 14 2010 Steven Pritchard  2.04-1
+- Update to 2.04.
+- Fix find option order.
+- Use fixperms macro instead of our own chmod incantation.
+- Update Source0 URL.
+- Minor cosmetic changes to resemble cpanspec output.
+- BR Module::Build and build with that.
+- BR Test::More.
+
 * Mon May 03 2010 Marcela Maslanova  - 2.01-10
 - Mass rebuild with perl-5.12.0
 
diff --git a/sources b/sources
index 6cbedf4..6426bfb 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-99550ae2cffbc0bb3eb0358631077c10  MLDBM-2.01.tar.gz
+b2793c419136fc11082e1ed1b564aeff  MLDBM-2.04.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


Broken dependencies: perl-AnyEvent

2010-12-14 Thread buildsys


perl-AnyEvent has broken dependencies in the epel-6 tree:
On x86_64:
perl-AnyEvent-5.27-1.el6.noarch requires perl(Event::Lib)
perl-AnyEvent-5.27-1.el6.noarch requires perl(IO::Async::Handle)
On i386:
perl-AnyEvent-5.27-1.el6.noarch requires perl(Event::Lib)
perl-AnyEvent-5.27-1.el6.noarch requires perl(IO::Async::Handle)
On ppc64:
perl-AnyEvent-5.27-1.el6.noarch requires perl(Event::Lib)
perl-AnyEvent-5.27-1.el6.noarch requires perl(IO::Async::Handle)
Please resolve this as soon as possible.


--
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: noexec on /dev/shm

2010-12-14 Thread Miloslav Trmač
Jesse Keating píše v Út 14. 12. 2010 v 09:47 -0800:
> On 12/14/10 9:22 AM, Miloslav Trmač wrote:
> > Bill Nottingham píše v Út 14. 12. 2010 v 12:08 -0500:
> >>> The problem is not the technical solution. Problem is that changes of
> >>> such important thing like /etc/fstab are decided without Fedora 
> >>> developers.
> >>
> >> Eh, what? It's a change to how API filesystems (/proc, /sys, etc.) get
> >> mounted. When this was done in rc.sysinit, every change to how it mounted
> >> /proc wasn't discussed on the devel list. When we switched to having dracut
> >> be the primary way that API filesystems are mounted, that wasn't put up
> >> to a FESCo vote.
> > The practical difference is that nothing broke at that time, whereas
> > systemd tends to break thinks that users use. (I won't buy dismissing it
> > as "mere bugs" - adding NOEXEC could hardly have been a typo.)

> 
> Perhaps you missed the part where the bug was that the fs doesn't get 
> remounted with the perms from fstab as by design.  That's the bug.
So the design was to
1) change the setting in the C reimplementation
2) add a new facility that will revert the setting to its original value
?

Is it really surprising that I'd like more discussion of the systemd
design in advance?
Mirek

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: noexec on /dev/shm

2010-12-14 Thread Chris Adams
Once upon a time, Bill Nottingham  said:
>   having every system
>   installer have to write /proc, /sys, and so on is pretty wasteful.

I've seen this said at least a couple of times.  In what way is it
"wasteful"?  On most systems, /etc/fstab is going to be less than one
filesystem block anyway, so there is absolutely zero "waste" going on.

If "waste" of a few dozen bytes is now an issue, /etc/fstab is hardly
the place to start.

-- 
Chris Adams 
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel


File MLDBM-2.04.tar.gz uploaded to lookaside cache by steve

2010-12-14 Thread Steven Pritchard
A file has been added to the lookaside cache for perl-MLDBM:

b2793c419136fc11082e1ed1b564aeff  MLDBM-2.04.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


Broken dependencies: rt3

2010-12-14 Thread buildsys


rt3 has broken dependencies in the epel-6 tree:
On x86_64:
perl-RT-Test-3.8.8-2.el6.noarch requires perl(Test::Email)
On i386:
perl-RT-Test-3.8.8-2.el6.noarch requires perl(Test::Email)
On ppc64:
perl-RT-Test-3.8.8-2.el6.noarch requires perl(Test::Email)
Please resolve this as soon as possible.


--
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


Broken dependencies: perl-Text-vFile-asData

2010-12-14 Thread buildsys


perl-Text-vFile-asData has broken dependencies in the epel-6 tree:
On x86_64:
perl-Text-vFile-asData-utils-0.05-4.el6.noarch requires 
perl(DateTime::Span)
perl-Text-vFile-asData-utils-0.05-4.el6.noarch requires 
perl(DateTime::Format::ICal)
On i386:
perl-Text-vFile-asData-utils-0.05-4.el6.noarch requires 
perl(DateTime::Span)
perl-Text-vFile-asData-utils-0.05-4.el6.noarch requires 
perl(DateTime::Format::ICal)
On ppc64:
perl-Text-vFile-asData-utils-0.05-4.el6.noarch requires 
perl(DateTime::Span)
perl-Text-vFile-asData-utils-0.05-4.el6.noarch requires 
perl(DateTime::Format::ICal)
Please resolve this as soon as possible.


--
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: [389-devel] Please review: [Bug 182507] clear-password mod from replica is discarded before changelogged

2010-12-14 Thread Noriko Hosoi
  Hi Andrey,

Andrey Ivanov wrote:
> Hi Noriko,
>
> i've read the changelog encryption design document. Indeed, it's a
> sound idea to make AD-389 replication more robust. I have two
> questions about it:
>
> * if i understand correctly you say that the server needs a
> certificate in order to generate the symmetric key. Is this key
> generated only once?
That is correct.  If a wrapped symmetric key is not found in 
cn=changelog5,cn=config, the key is generated.
> I mean, if we change the expired server
> certificate it won't trigger the symmetric key regeneration?
That's tricky.  If your changelog DB contains 2 sets of encrypted value 
-- one is encrypted with the expired cert, the other with the new cert, 
it'd be hard to recover old ones.  Automation makes it happen easier...
> * The replication changelog that contains the mixed entries
> (cleartext, encrypted 3DES, encrypted AES etc) - is it still readable
> by the server?
I don't think so.  We should avoid it, too.
> Does each changelog entry contain a flag that describes
> whether the entry is cleartext/AES/3DES? Can the server "detect" in
> any other way whether the changelog entry is encrypted and if yes with
> what type of cypher?
The answer is no.  Each value has no info about the type -- 
cleartext/AES/3DES.

Thanks for the questions, Andrey!
--noriko

--
389-devel mailing list
389-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-devel


Re: noexec on /dev/shm

2010-12-14 Thread Jesse Keating
On 12/14/10 9:22 AM, Miloslav Trmač wrote:
> Bill Nottingham píše v Út 14. 12. 2010 v 12:08 -0500:
>>> The problem is not the technical solution. Problem is that changes of
>>> such important thing like /etc/fstab are decided without Fedora developers.
>>
>> Eh, what? It's a change to how API filesystems (/proc, /sys, etc.) get
>> mounted. When this was done in rc.sysinit, every change to how it mounted
>> /proc wasn't discussed on the devel list. When we switched to having dracut
>> be the primary way that API filesystems are mounted, that wasn't put up
>> to a FESCo vote.
> The practical difference is that nothing broke at that time, whereas
> systemd tends to break thinks that users use. (I won't buy dismissing it
> as "mere bugs" - adding NOEXEC could hardly have been a typo.)
>   Mirek
>


Perhaps you missed the part where the bug was that the fs doesn't get 
remounted with the perms from fstab as by design.  That's the bug.

Lets have a little less chest pounding and a little more constructive 
discussion, mkay?

-- 
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

[Bug 663069] Wrong charset in graph.

2010-12-14 Thread bugzilla
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=663069

Vojtech Vitek  changed:

   What|Removed |Added

Version|6.3 |el6
  Component|zip |rt3
 CC||fedora-perl-devel-l...@redh
   ||at.com, mma...@redhat.com,
   ||trem...@tremble.org.uk,
   ||xav...@bachelot.org
 AssignedTo|vvi...@redhat.com   |xav...@bachelot.org
  QAContact|qe-baseos-a...@redhat.com   |extras...@fedoraproject.org
   Target Milestone|rc  |---
Product|Red Hat Enterprise Linux 6  |Fedora EPEL

-- 
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


Re: noexec on /dev/shm

2010-12-14 Thread Miloslav Trmač
Bill Nottingham píše v Út 14. 12. 2010 v 12:08 -0500:
> > The problem is not the technical solution. Problem is that changes of
> > such important thing like /etc/fstab are decided without Fedora developers.
> 
> Eh, what? It's a change to how API filesystems (/proc, /sys, etc.) get
> mounted. When this was done in rc.sysinit, every change to how it mounted
> /proc wasn't discussed on the devel list. When we switched to having dracut
> be the primary way that API filesystems are mounted, that wasn't put up
> to a FESCo vote. 
The practical difference is that nothing broke at that time, whereas
systemd tends to break thinks that users use. (I won't buy dismissing it
as "mere bugs" - adding NOEXEC could hardly have been a typo.)
Mirek

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

[Bug 662811] perl-CSS-DOM-0.14 is available

2010-12-14 Thread bugzilla
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=662811

Ville Skyttä  changed:

   What|Removed |Added

 Status|ASSIGNED|CLOSED
   Fixed In Version||0.14-1
 Resolution||RAWHIDE
Last Closed||2010-12-14 12:08:37

-- 
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

Re: noexec on /dev/shm

2010-12-14 Thread Bill Nottingham
Marcela Mašláňová (mmasl...@redhat.com) said: 
> >>> That's not a very constructive wording. Filing a bug showing your use-case
> >>> would be helpful.

I'd like to restate this point. It's rather disappointing that so many
people have decided to skip over this, and prefer to instead complain,
insinuate, and argue on list rather than starting with this simple,
more likely to be productive, action.

> The problem is not the technical solution. Problem is that changes of
> such important thing like /etc/fstab are decided without Fedora developers.

Eh, what? It's a change to how API filesystems (/proc, /sys, etc.) get
mounted. When this was done in rc.sysinit, every change to how it mounted
/proc wasn't discussed on the devel list. When we switched to having dracut
be the primary way that API filesystems are mounted, that wasn't put up
to a FESCo vote. 

And it's also not fair to say that 'Fedora developers' aren't involved;
heck, there's at least 10 of them on the systemd mailing list, by a quick
count. If you mean, "it wasn't posted to devel@, or it wasn't brought to
FESCo", well, we don't review every change to upstream packages in this
way... if we did, we'd be drowned in minutiae. I mean, I could have brought
the addition on how to add multiple IPv4 addresses to interfaces to FESCo
for discussion and vote, but I've got better things to do with my time.

In any case, I'm pretty sure it's not even intentional. systemd has
two areas of mounting:

- systemd mounts API filesystems without them needing to be in
  /etc/fstab. This is for a variety of reasons - having every system
  installer have to write /proc, /sys, and so on is pretty wasteful. It
  also can give inexperienced admins the idea that it's configuration
  that can be changed - they then rename the mount point from /proc
  to /processes and *kaboom*.
- systemd mounts system filesystems from /etc/fstab. This includes
  mount options, etc., and (I'd think) would be fairly uncontroversial.

The first of these happens before the second (as you obviously need
/proc, /sys, etc. very early), however systemd already has
/lib/systemd/system/systemd-remount-api-vfs.service:

...
[Unit]
Description=Remount API VFS
...
ExecStart=/lib/systemd/systemd-remount-api-vfs
...

And if you look at that code:

/* Goes through /etc/fstab and remounts all API file systems, applying
 * options that are in /etc/fstab that systemd might not have
 * respected */

So, it just looks like an ordinary bug. File it, we can get it fixed,
and we can all live happily ever after.

Bill
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: noexec on /dev/shm

2010-12-14 Thread Matthew Miller
On Tue, Dec 14, 2010 at 02:25:38PM +, Richard W.M. Jones wrote:
> I think it's very reasonable to want to edit /etc/fstab to change the
> default mount options of these filesystems.  Suppose that /dev/shm
> defaults to allowing suid and exec.  At some point in the future a
> security problem is found which can be worked around by temporarily
> setting nosuid on /dev/shm (while the real issue is fixed).  An
> administrator can't do that without recompiling systemd.

I'm not sure there's a win in having systemd do magic rather than just using
fstab -- reminds me of IRIX and its auto-mounting of some but not all swap
partitions. (Yay newbie admin confusion!)

But if there's a good technical reason, it still seems reasonable to let
/etc/fstab override the defaults.


-- 
Matthew Miller 
Senior Systems Architect -- Instructional & Research Computing Services
Harvard School of Engineering & Applied Sciences
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel


Re: Safest way to go from x86 to x86_64

2010-12-14 Thread Bill Nottingham
Richard W.M. Jones (rjo...@redhat.com) said: 
> I guess you can do:
> 
> rpm -qa --qf '%{name}\n' > kickstart
> 
> and try to construct a kickstart file out of that ...

Using 'show-installed' from rawhide yum-utils (works on earlier releases
if you copy the script over) can give you a more compact kickstart which
will be processed quicker.

Bill
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel


Re: [389-devel] Problem using winsync API

2010-12-14 Thread Nathan Kinder

On 12/13/2010 12:45 AM, Carsten Grzemba wrote:

I found the reason: In winsync-plugin.h in the plugin config is defined a 
dependenciy for multi-master plugin. This seems to be wrong, because a Winsync 
plugin must already be registered when the multi-master plugin starts. I.e. the 
dependency should be reversed. The multi-master Plugin depends on the Winsync 
plugin.

I have removed

nsslapd-plugin-depends-on-named: Multimaster Replication Plugin

from the plugin configuration, and instead added the Multimaster Plugin config

nsslapd-plugin-depends-on-named: test Winsync API

Then, the Winsync plugin is loaded also if start / restart the directory server.
Can you review this?
Could you supply your plug-in code?  You need to be calling 
slapi_apib_register() to register your API in your plug-in's init() 
function.  I'm curious to see if you are doing this in the init() 
callback, or in the start() callback.


-NGK

Regards

- Ursprüngliche Nachricht -
Von: Rich Megginson
Datum: Samstag, 11. Dezember 2010, 0:59
Betreff: Re: [389-devel] Problem using winsync API
An: 389-de...@lists.fedoraproject.org







On 12/08/2010 05:17 AM, Carsten Grzemba wrote:

  >
- Ursprüngliche Nachricht -
Von: Carsten Grzemba
Datum: Mittwoch, 8. Dezember 2010, 11:16
Betreff: [389-devel] Problem using winsync API
An: "389 Directory server developer 
discussion."<389-de...@lists.fedoraproject.org>



I try to use the Winsync API. The _winsync_plugin_init and
_winsync_plugin_start functions are called, but apparently not
correctly registered.
If the actual functions should be called, nothing happens.
Debbuging shows the pointer thefunc in windows_private.c
functions is NIL.


  it works only after the creation of an winsync replication agreement. 
After restart the directoryserver only _winsync_plugin_init and 
_winsync_plugin_start are called.


So is there still a problem?



>  Does anyone know why this is?
Thanks
Carsten



  --


389-devel mailing list
389-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-devel

>
--
389-devel mailing list
389-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-devel







--

389-devel mailing list
389-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-devel


--
389-devel mailing list
389-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-devel


--
389-devel mailing list
389-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-devel

Re: Safest way to go from x86 to x86_64

2010-12-14 Thread Matt McCutchen
On Tue, 2010-12-14 at 14:07 +, Paul Johnson wrote:
> Hi,
> 
> My main box decided to snuff it last week (motherboard and processor
> decided to fry). My erstwhile friend in the computer shop I use has
> said that he has a nice 64 bit processor and motherboard going for a
> small amount of money.
> 
> The problem I have is that if I go the 64 bit route then I'll need to
> install the 64 bit OS (I can stay 32 bit, but what's the point with
> 8Gb of memory).
> 
> Is there a safe way to install the x86_64 system over the 32 bit
> version and then clean off the 32 bit stuff that is no longer needed?

I did that to my Fedora 11 system in October 2009.  It took a
significant amount of manual work and scripting and I hit a number of
minor issues.  I'm not sure I would call the procedure "safe", but it
did work.  The procedure was like this:

- Change /etc/rpm/platform to x86_64-redhat-linux and put
"%_transaction_color 3" in /etc/rpm/macros .
- Install the x86_64 kernel and boot to it.
- Install the x86_64 version of rpm.
- Construct a yum script with "install" lines for the x86_64 versions of
all installed packages.  Repeatedly try to run the script and add
"erase" lines for any i?86 packages that cause file conflicts until it
succeeds.
- Watch the output.  When scriptlets fail, fix things manually.
- Remove all unneeded i?86 packages.  I needed to keep a few proprietary
packages that are only available for i?86, so I used a script to walk
the dependencies and figure out which i?86 packages could be removed.

YMMV with rawhide.

-- 
Matt

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel


Re: abrt wishlist

2010-12-14 Thread Jiri Moskovcak
On 12/14/2010 05:14 PM, Jaroslav Reznik wrote:
> On Tuesday, December 14, 2010 03:19:32 pm Jiri Moskovcak wrote:
>> On 12/14/2010 02:54 PM, Karel Klic wrote:
 - Separating machine-generated content from human-generated content is
 valuable for the developer.  The two require different mental processes
 to handle.  I have a much stronger guarantee that the abrt bug contains
 facts, but I also know there's no point in asking for more information.
 Reading a crash report is looking at structured data and divining
 patterns.  Reading a human's bug report is listening to a story.  Left
 brain, right brain.
>>>
>>> Good point.
>>>
>>> ABRT has become more slanted towards machine-generated bug reports
>>> unintentionally, mostly because the user interface and report format
>>> turned out this way: the implicit assumption that everything should be
>>> reported (and reported without much effort) is present in many aspects,
>>> e.g. the red "warning" sign for every unreported crash, green "you did
>>> good thing" sign for reported ones.
>>>
>>> The idea of an application only _assisting_ user to create human-made
>>> bug reports and making it easy to append the underlying technical
>>> information is still worth pursuing. It is only a matter of changing the
>>> ABRT interface to guide users this way, and to separate this way from
>>> semi-automatic crash reporting.
>>
>> - btw, we tried that with making the howto field mandatory and I already
>> saw some reports saying "I don't have a damn clue how to reproduce it,
>> but this stupid ABRT thing won't let me continue" :))
>
> Educate people that such bug report is just useless as usually it is.
>

How? Maybe I just don't understand, but if there is a way how to 
autodetect that the user input is useless then we'll add it, but analyse 
the text and try to guess if it's useless or not is really not trivial...

J.

> R.
>
>>
>>> It aslo makes sense to allow sending mostly machine-generated, few click
>>> "crash" reports to some new server/service. It should be possible to
>>> combine both approaches in a single application with some UI design
>>> thinking. We can change ABRT to encourage sending computer assisted,
>>> mostly human written bug reports to Bugzilla, and to enable
>>> semi-automatic crash reporting to some new server. Two ways of
>>> reporting. Not trying to combine them together as it is done now.
>>>
>>> Karel
>>
>> The problem is, that with ABRT we probably get more people involved in
>> reporting bugs - which I think is great (would be a nice statistic to
>> see if/how the number of new accounts has grown since ABRT) but unlike
>> the older reporters with a good habits these new reporters won't create
>> a good report using neither bz or ABRT... so yes, we need to change the
>> UI to treat the reporters as they (the reporter rookies) deserve.. ABRT
>> GUI should be more like "Assisted Bug Reporting for Dummies" :)) ->  ABRD :)
>>
>> J.
>

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel


[perl-Algorithm-Annotate] - 661697 rebuild for fixing problems with vendorach/lib

2010-12-14 Thread Marcela Mašláňová
commit fb677232a6c9fb67b9a19f36dbca83021eec4bac
Author: Marcela Mašláňová 
Date:   Tue Dec 14 17:09:38 2010 +0100

- 661697 rebuild for fixing problems with vendorach/lib

 perl-Algorithm-Annotate.spec |5 -
 1 files changed, 4 insertions(+), 1 deletions(-)
---
diff --git a/perl-Algorithm-Annotate.spec b/perl-Algorithm-Annotate.spec
index 7d3241d..a79176b 100644
--- a/perl-Algorithm-Annotate.spec
+++ b/perl-Algorithm-Annotate.spec
@@ -1,6 +1,6 @@
 Name:   perl-Algorithm-Annotate
 Version:0.10
-Release:10%{?dist}
+Release:11%{?dist}
 Summary:Represent a series of changes in annotate form
 License:GPL+ or Artistic
 Group:  Development/Libraries
@@ -46,6 +46,9 @@ rm -rf $RPM_BUILD_ROOT
 %{_mandir}/man3/*
 
 %changelog
+* Tue Dec 14 2010 Marcela Maslanova  - 0.10-11
+- 661697 rebuild for fixing problems with vendorach/lib
+
 * Thu Apr 29 2010 Marcela Maslanova  - 0.10-10
 - Mass rebuild with perl-5.12.0
 
--
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-Affix-Infix2Postfix] - 661697 rebuild for fixing problems with vendorach/lib

2010-12-14 Thread Marcela Mašláňová
commit 784c308f8216f1335a1aac53cb4f4b47dafdd566
Author: Marcela Mašláňová 
Date:   Tue Dec 14 17:04:42 2010 +0100

- 661697 rebuild for fixing problems with vendorach/lib

 perl-Affix-Infix2Postfix.spec |5 -
 1 files changed, 4 insertions(+), 1 deletions(-)
---
diff --git a/perl-Affix-Infix2Postfix.spec b/perl-Affix-Infix2Postfix.spec
index 2f5c3b5..d886279 100644
--- a/perl-Affix-Infix2Postfix.spec
+++ b/perl-Affix-Infix2Postfix.spec
@@ -1,6 +1,6 @@
 Name:   perl-Affix-Infix2Postfix
 Version:0.03
-Release:6%{?dist}
+Release:7%{?dist}
 Summary:Perl extension for converting from infix notation to postfix 
notation
 License:GPL+ or Artistic
 Group:  Development/Libraries
@@ -49,6 +49,9 @@ rm -rf $RPM_BUILD_ROOT
 %{_mandir}/man3/*
 
 %changelog
+* Tue Dec 14 2010 Marcela Maslanova  - 0.03-7
+- 661697 rebuild for fixing problems with vendorach/lib
+
 * Thu Apr 29 2010 Marcela Maslanova  - 0.03-6
 - Mass rebuild with perl-5.12.0
 
--
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: noexec on /dev/shm

2010-12-14 Thread Paul Wouters
On Tue, 14 Dec 2010, Tomasz Torcz wrote:

>  We saw it includes /dev, /dev/shm etc.  Is there any *reasonable* need
> to mount sysfs somewhere else than /sys. Or /dev with mode other than 755?
> Those all directories are mounted _identically_ on every Linux distribution
> down here.  Why pollute fstab with repeated lines on million machines?

Because the system is meant to be changable by people. What if 20 years ago
people had harcoded /usr and /var because they knew best? Things change
over time and the unix philosphy is to allow that.

The other thing is that options where possible should be in human readable
format to make understanding and changing it easier. /etc/fstab sure beats
some hardcoded binary.

You are reversing the logic. Keep the system flexible and transparent.

The less we put hardcoded inside the kernel, initrd, pivot root, dracut,
linuxrc or systemd the better. It is easier to change a config line then
to recompile software. Don't assume you can speak for everyone with your
use cases.

>  Original problem could be solved by configuring some scratch
> tmpfs in /mnt/scratch or somewhere else.

the original problem i think was more "I dont understand why my fstab
seems to be acting up".

The fstab file itself provides valuable documentation of implicit values. Even
if I never change it, I use it.

Paul
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel


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

2010-12-14 Thread Henrik Nordström
tis 2010-12-07 klockan 10:20 -0800 skrev Jesse Keating:
> While I'm looking into the git setup and ACLs and all this, I have a
> question.
> 
> 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...?

Can't see any.

The only use I see is to allow people to indicate retirement and show a
record of "I did maintain in earlier Fedora releases but no longer", but
that info is much better displayed by other means than the acl
memberships.

Regards
Henrik

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel


Re: End of life in bugzilla, how to reopen?

2010-12-14 Thread Henrik Nordström
tis 2010-12-07 klockan 20:53 +0100 skrev Andreas Tunek:

> Shouldn't the end of life message reflect that then? It should tell me
> to contact a bug zapper to move the bug report.

I think the reporter can move the bug report as well. At least I have a
memory of doing so on some of the bugs I have filed earlier.

Regards
Henrik

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel


Re: Proposed package blocking due to FTBFS

2010-12-14 Thread Henrik Nordström
ons 2010-12-08 klockan 11:41 + skrev Peter Robinson:

> It was my understanding that abrt was suppose to block on backtraces
> without debuginfo but I still regularly get bugs with little or no
> decent info.

True. I accidently filed a such abrt report some time ago. I assumed it
would fetch the needed debug info as I am used to but for some reason it
did not.

>  What's worse is often they are the first report and abrt
> de-dupes against that report and still doesn't automatically either
> update the backtrace with a complete one from other reports or attach
> a new one.

Yes, that slowed down processing of the above bug quite a lot.

Regards
Henrik


-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel


Re: Safest way to go from x86 to x86_64

2010-12-14 Thread Richard W.M. Jones
On Tue, Dec 14, 2010 at 02:35:24PM +, Paul Johnson wrote:
> Hi,
> 
> On 14 December 2010 14:27, Richard W.M. Jones  wrote:
> 
> > On Tue, Dec 14, 2010 at 02:07:37PM +, Paul Johnson wrote:
> >
> > > Is there a safe way to install the x86_64 system over the 32 bit version
> > and
> > > then clean off the 32 bit stuff that is no longer needed? If I was using
> > > f14, I'd just trash the drive and then install, but I've got things how I
> > > want them under rawhide.
> >
> > Not really.  I would definitely suggest that you reinstall.
> >
> > I thought that would be the case - just wanted to check to ensure it's not
> something I can do another way.
> 
> Okay, let's try another. Is there a way to grab a list of the packages
> installed and use a network installer to do the job based on the list?

I guess you can do:

rpm -qa --qf '%{name}\n' > kickstart

and try to construct a kickstart file out of that ...

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: Safest way to go from x86 to x86_64

2010-12-14 Thread seth vidal
On Tue, 2010-12-14 at 14:35 +, Paul Johnson wrote:
> Hi,
> 
> On 14 December 2010 14:27, Richard W.M. Jones 
> wrote:
> On Tue, Dec 14, 2010 at 02:07:37PM +, Paul Johnson wrote:
> 
> > Is there a safe way to install the x86_64 system over the 32
> bit version and
> > then clean off the 32 bit stuff that is no longer needed? If
> I was using
> > f14, I'd just trash the drive and then install, but I've got
> things how I
> > want them under rawhide.
> 
> 
> Not really.  I would definitely suggest that you reinstall.
> 
> I thought that would be the case - just wanted to check to ensure it's
> not something I can do another way.
> 
> Okay, let's try another. Is there a way to grab a list of the packages
> installed and use a network installer to do the job based on the list?
> 

sure - kickstart does just that.

-sv



-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel


Re: Safest way to go from x86 to x86_64

2010-12-14 Thread Paul Johnson
Hi,

On 14 December 2010 14:27, Richard W.M. Jones  wrote:

> On Tue, Dec 14, 2010 at 02:07:37PM +, Paul Johnson wrote:
>
> > Is there a safe way to install the x86_64 system over the 32 bit version
> and
> > then clean off the 32 bit stuff that is no longer needed? If I was using
> > f14, I'd just trash the drive and then install, but I've got things how I
> > want them under rawhide.
>
> Not really.  I would definitely suggest that you reinstall.
>
> I thought that would be the case - just wanted to check to ensure it's not
something I can do another way.

Okay, let's try another. Is there a way to grab a list of the packages
installed and use a network installer to do the job based on the list?

TTFN

Paul
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: old_testing_critpath notifications

2010-12-14 Thread Henrik Nordström
tis 2010-12-07 klockan 19:20 -0500 skrev Doug Ledford:

> For non-boot devices, loopback works.  You only need the hardware if you
> are testing boot time capabilities (which, admittedly, is the far more
> important aspect of testing for this package).

And if you don't have spare systems with more than one drive to play
around with then kvm virtualization comes to the rescue when testing
pretty much any md or dm issue, possibly even including multipath.

Regards
Henrik

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel


Re: Safest way to go from x86 to x86_64

2010-12-14 Thread Richard W.M. Jones
On Tue, Dec 14, 2010 at 02:07:37PM +, Paul Johnson wrote:
> Hi,
> 
> My main box decided to snuff it last week (motherboard and processor decided
> to fry). My erstwhile friend in the computer shop I use has said that he has
> a nice 64 bit processor and motherboard going for a small amount of money.
> 
> The problem I have is that if I go the 64 bit route then I'll need to
> install the 64 bit OS (I can stay 32 bit, but what's the point with 8Gb of
> memory).
> 
> Is there a safe way to install the x86_64 system over the 32 bit version and
> then clean off the 32 bit stuff that is no longer needed? If I was using
> f14, I'd just trash the drive and then install, but I've got things how I
> want them under rawhide.

Not really.  I would definitely suggest that you reinstall.

I've been using x86-64 machines routinely for 6 years now, and they
are better in every way than i386.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
virt-df lists disk usage of guests without needing to install any
software inside the virtual machine.  Supports Linux and Windows.
http://et.redhat.com/~rjones/virt-df/
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel


Re: noexec on /dev/shm

2010-12-14 Thread Richard W.M. Jones
On Tue, Dec 14, 2010 at 02:24:53PM +0100, Tomasz Torcz wrote:
>   We saw it includes /dev, /dev/shm etc.  Is there any *reasonable* need
> to mount sysfs somewhere else than /sys. Or /dev with mode other than 755?
> Those all directories are mounted _identically_ on every Linux distribution
> down here.  Why pollute fstab with repeated lines on million machines?

The issue here isn't that the reporter wanted to mount them somewhere
else, but he wanted to set the default mount options to something else
(or in fact to set them back to how they are now -- systemd has
decided to use some other mount options entirely without consulting
anyone else).

I think it's very reasonable to want to edit /etc/fstab to change the
default mount options of these filesystems.  Suppose that /dev/shm
defaults to allowing suid and exec.  At some point in the future a
security problem is found which can be worked around by temporarily
setting nosuid on /dev/shm (while the real issue is fixed).  An
administrator can't do that without recompiling systemd.

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: noexec on /dev/shm

2010-12-14 Thread Miloslav Trmač
Marcela Mašláňová píše v Út 14. 12. 2010 v 14:55 +0100:
> On 12/14/2010 02:24 PM, Tomasz Torcz wrote:
> > On Tue, Dec 14, 2010 at 01:53:37PM +0100, Miloslav Trmač wrote:
> >> Changing the semantics of /etc/fstab without any consultation with
> >> fedora-devel or even notification of Fedora that something so
> >> long-standing is changing is hardly constructive either.
> >>
> >> I can happily live with "systemd is a new, better init system" without
> >> knowing the details.  I consider "systemd replaces 15% of /etc and
> >> changes semantics of another 5%" without discussing the details in
> >> advance unacceptable for the distribution as a whole, although this
> >> decision is of course FESCo's.
> >>Mirek
> >   Let's keep discussion calm and technical.  
> >  “Systemd contains native implementations of various tasks that need to
> >  be executed as part of the boot process. For example, it sets the host 
> > name 
> > or configures the loopback network device. It also sets up and
> >mounts various API file systems, such as /sys or /proc.”
> >
> >   We saw it includes /dev, /dev/shm etc.  Is there any *reasonable* need
> > to mount sysfs somewhere else than /sys. Or /dev with mode other than 755?
> > Those all directories are mounted _identically_ on every Linux distribution
> > down here.  Why pollute fstab with repeated lines on million machines?
> >
> >   I can see that it may look like taking power from admin, but has
> > anyone ever changed how devpts is mounted?  Really?  Being able
> > to change for the sake of ability is not always sane.  There are
> > things which we can change, and some things which shouldn't be touched
> > by admin.  And I'm not proposing dumbing down admin.  Back when
> > I run Slackware I rewrote part of the initscripts to suit me.
> > But really, admin should worry about important things, better
> > leave boring (and identical across distros) parts to someone else.
> >
> >   Original problem could be solved by configuring some scratch
> > tmpfs in /mnt/scratch or somewhere else.
> >
> The problem is not the technical solution. Problem is that changes of
> such important thing like /etc/fstab are decided without Fedora developers.
> Usually such change would be discussed before on list and it would be
> feature for new Fedora. It's not even mentioned on Systemd Feature page.
+1

This is (was?) UNIX.  No single person knows about all the creative and
important ways that users have configured the system to suit their
needs.  Dropping system-wide features should be a conscious decision,
not something we accidentally discover several months later when user
complaints start to come in.
Mirek

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: A GUI tool for Fedora Packagers

2010-12-14 Thread Mat Booth
On 14 December 2010 03:46, Chris Aniszczyk (zx)  wrote:
> The Eclipse team within Red Hat has already developed something called the 
> Eclipse Fedora Packager:
>     http://lists.fedoraproject.org/pipermail/devel/2010-October/144570.html
>     http://fedoraproject.org/wiki/Eclipse_Fedora_Packager_User_Guide
>
> It's still in beta but essentially does what you describe.
>
> At the moment, it integrates within the Eclipse IDE but can be modified to be 
> more standalone if desired.
>
> Cheers,
>

I have been using eclipse-fedorapackager for a while now and it works
quite well, thanks for the effort that has gone into it.

My life revolves around Eclipse at my day job so using this plug-in
wasn't a leap, but I've found that many people who aren't developers
find Eclipse quite an overly large and intimidating product so maybe a
little RCP app would be quite neat for people who don't need a full
blown IDE. :-)

-- 
Mat Booth
http://fedoraproject.org/get-fedora
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel


Re: Retired package by mistake - undo?

2010-12-14 Thread Gilboa Davara
On Tue, 2010-12-14 at 08:19 -0600, Jason L Tibbitts III wrote:
> OK, I found spring-installer and unretired it as well.  You should log
> into pkgdb and claim both packages as they're currently orphaned.
> 
>  - J<

Thanks!

- Gilboa

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel


Re: abrt wishlist

2010-12-14 Thread Jiri Moskovcak
On 12/14/2010 02:54 PM, Karel Klic wrote:
>> - Separating machine-generated content from human-generated content is
>> valuable for the developer.  The two require different mental processes
>> to handle.  I have a much stronger guarantee that the abrt bug contains
>> facts, but I also know there's no point in asking for more information.
>> Reading a crash report is looking at structured data and divining
>> patterns.  Reading a human's bug report is listening to a story.  Left
>> brain, right brain.
>
> Good point.
>
> ABRT has become more slanted towards machine-generated bug reports
> unintentionally, mostly because the user interface and report format
> turned out this way: the implicit assumption that everything should be
> reported (and reported without much effort) is present in many aspects,
> e.g. the red "warning" sign for every unreported crash, green "you did
> good thing" sign for reported ones.
>
> The idea of an application only _assisting_ user to create human-made
> bug reports and making it easy to append the underlying technical
> information is still worth pursuing. It is only a matter of changing the
> ABRT interface to guide users this way, and to separate this way from
> semi-automatic crash reporting.
>

- btw, we tried that with making the howto field mandatory and I already 
saw some reports saying "I don't have a damn clue how to reproduce it, 
but this stupid ABRT thing won't let me continue" :))

> It aslo makes sense to allow sending mostly machine-generated, few click
> "crash" reports to some new server/service. It should be possible to
> combine both approaches in a single application with some UI design
> thinking. We can change ABRT to encourage sending computer assisted,
> mostly human written bug reports to Bugzilla, and to enable
> semi-automatic crash reporting to some new server. Two ways of
> reporting. Not trying to combine them together as it is done now.
>
> Karel

The problem is, that with ABRT we probably get more people involved in 
reporting bugs - which I think is great (would be a nice statistic to 
see if/how the number of new accounts has grown since ABRT) but unlike 
the older reporters with a good habits these new reporters won't create 
a good report using neither bz or ABRT... so yes, we need to change the 
UI to treat the reporters as they (the reporter rookies) deserve.. ABRT 
GUI should be more like "Assisted Bug Reporting for Dummies" :)) -> ABRD :)

J.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel


Re: Retired package by mistake - undo?

2010-12-14 Thread Jason L Tibbitts III
OK, I found spring-installer and unretired it as well.  You should log
into pkgdb and claim both packages as they're currently orphaned.

 - J<
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel


Re: Retired package by mistake - undo?

2010-12-14 Thread Jason L Tibbitts III
> "GD" == Gilboa Davara  writes:

GD> Hello all, While the click-frenzy required to take ownership over
GD> spring and its sub packages I mistakably retired spring-maps-default
GD> / devel and spring-install / devel. I tried to unretire them both,
GD> but failed.

You've found one of the worst ways to reach an admin, of course, but I
happened to notice your message.

I unretired spring-maps-default.  I can find no packages named
spring-maps-devel, spring-install or spring-devel in pkgdb.

 - J<
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel


Retired package by mistake - undo?

2010-12-14 Thread Gilboa Davara
Hello all,

While the click-frenzy required to take ownership over spring and its
sub packages I mistakably retired spring-maps-default / devel and
spring-install / devel.
I tried to unretire them both, but failed.

Admins, help?

- Gilboa 

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel


Re: noexec on /dev/shm

2010-12-14 Thread Chris Adams
Once upon a time, Tomasz Torcz  said:
>   We saw it includes /dev, /dev/shm etc.  Is there any *reasonable* need
> to mount sysfs somewhere else than /sys. Or /dev with mode other than 755?
> Those all directories are mounted _identically_ on every Linux distribution
> down here.  Why pollute fstab with repeated lines on million machines?

What is the advantage to making some mounts not listed in the file with
all the other mounts?  It isn't like /etc/fstab is a hundred lines or
anything; it is a standard config file that predates Linux.  All mounts
are listed there until systemd decided to override it (without any
warning or documentation).

-- 
Chris Adams 
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel


Safest way to go from x86 to x86_64

2010-12-14 Thread Paul Johnson
Hi,

My main box decided to snuff it last week (motherboard and processor decided
to fry). My erstwhile friend in the computer shop I use has said that he has
a nice 64 bit processor and motherboard going for a small amount of money.

The problem I have is that if I go the 64 bit route then I'll need to
install the 64 bit OS (I can stay 32 bit, but what's the point with 8Gb of
memory).

Is there a safe way to install the x86_64 system over the 32 bit version and
then clean off the 32 bit stuff that is no longer needed? If I was using
f14, I'd just trash the drive and then install, but I've got things how I
want them under rawhide.

I've not done this before, so advice before I do it would be appreciated.

TTFN

Paul
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: noexec on /dev/shm

2010-12-14 Thread Marcela Mašláňová
On 12/14/2010 02:24 PM, Tomasz Torcz wrote:
> On Tue, Dec 14, 2010 at 01:53:37PM +0100, Miloslav Trmač wrote:
>> Matthew Miller píše v Út 14. 12. 2010 v 07:39 -0500:
>>> On Mon, Dec 13, 2010 at 11:57:51PM +0100, Dominik 'Rathann' Mierzejewski 
>>> wrote:
> the MS_NOEXEC flags is in private systemd fstab, see
> systemd/src/mount-setup.c:
 You're not kidding. Could the author of this code (I'm guessing...
 Lennart?) please explain this extremely bright idea of hard-coding
 what should be admin-configurable?
>>> That's not a very constructive wording. Filing a bug showing your use-case
>>> would be helpful.
>> Changing the semantics of /etc/fstab without any consultation with
>> fedora-devel or even notification of Fedora that something so
>> long-standing is changing is hardly constructive either.
>>
>> I can happily live with "systemd is a new, better init system" without
>> knowing the details.  I consider "systemd replaces 15% of /etc and
>> changes semantics of another 5%" without discussing the details in
>> advance unacceptable for the distribution as a whole, although this
>> decision is of course FESCo's.
>>  Mirek
>   Let's keep discussion calm and technical.  
>  “Systemd contains native implementations of various tasks that need to
>  be executed as part of the boot process. For example, it sets the host name 
> or configures the loopback network device. It also sets up and
>mounts various API file systems, such as /sys or /proc.”
>
>   We saw it includes /dev, /dev/shm etc.  Is there any *reasonable* need
> to mount sysfs somewhere else than /sys. Or /dev with mode other than 755?
> Those all directories are mounted _identically_ on every Linux distribution
> down here.  Why pollute fstab with repeated lines on million machines?
>
>   I can see that it may look like taking power from admin, but has
> anyone ever changed how devpts is mounted?  Really?  Being able
> to change for the sake of ability is not always sane.  There are
> things which we can change, and some things which shouldn't be touched
> by admin.  And I'm not proposing dumbing down admin.  Back when
> I run Slackware I rewrote part of the initscripts to suit me.
> But really, admin should worry about important things, better
> leave boring (and identical across distros) parts to someone else.
>
>   Original problem could be solved by configuring some scratch
> tmpfs in /mnt/scratch or somewhere else.
>
The problem is not the technical solution. Problem is that changes of
such important thing like /etc/fstab are decided without Fedora developers.
Usually such change would be discussed before on list and it would be
feature for new Fedora. It's not even mentioned on Systemd Feature page.

-- 
Marcela Mašláňová
BaseOS team Brno

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: abrt wishlist

2010-12-14 Thread Karel Klic
> - Separating machine-generated content from human-generated content is
> valuable for the developer.  The two require different mental processes
> to handle.  I have a much stronger guarantee that the abrt bug contains
> facts, but I also know there's no point in asking for more information.
> Reading a crash report is looking at structured data and divining
> patterns.  Reading a human's bug report is listening to a story.  Left
> brain, right brain.

Good point.

ABRT has become more slanted towards machine-generated bug reports 
unintentionally, mostly because the user interface and report format 
turned out this way: the implicit assumption that everything should be 
reported (and reported without much effort) is present in many aspects, 
e.g. the red "warning" sign for every unreported crash, green "you did 
good thing" sign for reported ones.

The idea of an application only _assisting_ user to create human-made 
bug reports and making it easy to append the underlying technical 
information is still worth pursuing. It is only a matter of changing the 
ABRT interface to guide users this way, and to separate this way from 
semi-automatic crash reporting.

It aslo makes sense to allow sending mostly machine-generated, few click 
"crash" reports to some new server/service. It should be possible to 
combine both approaches in a single application with some UI design 
thinking. We can change ABRT to encourage sending computer assisted, 
mostly human written bug reports to Bugzilla, and to enable 
semi-automatic crash reporting to some new server. Two ways of 
reporting. Not trying to combine them together as it is done now.

Karel
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel


Re: noexec on /dev/shm

2010-12-14 Thread Tomasz Torcz
On Tue, Dec 14, 2010 at 01:53:37PM +0100, Miloslav Trmač wrote:
> Matthew Miller píše v Út 14. 12. 2010 v 07:39 -0500:
> > On Mon, Dec 13, 2010 at 11:57:51PM +0100, Dominik 'Rathann' Mierzejewski 
> > wrote:
> > > > the MS_NOEXEC flags is in private systemd fstab, see
> > > > systemd/src/mount-setup.c:
> > > You're not kidding. Could the author of this code (I'm guessing...
> > > Lennart?) please explain this extremely bright idea of hard-coding
> > > what should be admin-configurable?
> > 
> > That's not a very constructive wording. Filing a bug showing your use-case
> > would be helpful.
> Changing the semantics of /etc/fstab without any consultation with
> fedora-devel or even notification of Fedora that something so
> long-standing is changing is hardly constructive either.
> 
> I can happily live with "systemd is a new, better init system" without
> knowing the details.  I consider "systemd replaces 15% of /etc and
> changes semantics of another 5%" without discussing the details in
> advance unacceptable for the distribution as a whole, although this
> decision is of course FESCo's.
>   Mirek

  Let's keep discussion calm and technical.  
 “Systemd contains native implementations of various tasks that need to
 be executed as part of the boot process. For example, it sets the host name 
or configures the loopback network device. It also sets up and
   mounts various API file systems, such as /sys or /proc.”

  We saw it includes /dev, /dev/shm etc.  Is there any *reasonable* need
to mount sysfs somewhere else than /sys. Or /dev with mode other than 755?
Those all directories are mounted _identically_ on every Linux distribution
down here.  Why pollute fstab with repeated lines on million machines?

  I can see that it may look like taking power from admin, but has
anyone ever changed how devpts is mounted?  Really?  Being able
to change for the sake of ability is not always sane.  There are
things which we can change, and some things which shouldn't be touched
by admin.  And I'm not proposing dumbing down admin.  Back when
I run Slackware I rewrote part of the initscripts to suit me.
But really, admin should worry about important things, better
leave boring (and identical across distros) parts to someone else.

  Original problem could be solved by configuring some scratch
tmpfs in /mnt/scratch or somewhere else.

-- 
Tomasz Torcz "God, root, what's the difference?"
xmpp: zdzich...@chrome.pl "God is more forgiving."

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Re: noexec on /dev/shm

2010-12-14 Thread dwayne

I will be away from 14 December 2010 to 7 January 2011. For Translate.org.za 
and ANLoc queries, please contact the office: +2712 460 1095 or info AT 
translate.org.za.


-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel


Re: noexec on /dev/shm

2010-12-14 Thread Miloslav Trmač
Matthew Miller píše v Út 14. 12. 2010 v 07:39 -0500:
> On Mon, Dec 13, 2010 at 11:57:51PM +0100, Dominik 'Rathann' Mierzejewski 
> wrote:
> > > the MS_NOEXEC flags is in private systemd fstab, see
> > > systemd/src/mount-setup.c:
> > You're not kidding. Could the author of this code (I'm guessing...
> > Lennart?) please explain this extremely bright idea of hard-coding
> > what should be admin-configurable?
> 
> That's not a very constructive wording. Filing a bug showing your use-case
> would be helpful.
Changing the semantics of /etc/fstab without any consultation with
fedora-devel or even notification of Fedora that something so
long-standing is changing is hardly constructive either.

I can happily live with "systemd is a new, better init system" without
knowing the details.  I consider "systemd replaces 15% of /etc and
changes semantics of another 5%" without discussing the details in
advance unacceptable for the distribution as a whole, although this
decision is of course FESCo's.
Mirek

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: noexec on /dev/shm

2010-12-14 Thread Richard W.M. Jones
On Mon, Dec 13, 2010 at 09:47:49AM -0600, Garrett Holmstrom wrote:
> If systemd is going to ignore fstab entries, could we please have the 
> fstab file on newly-installed systems replace the entries that would be 
> ignored with commentary that explains which filesystems will be ignored?
> 
> That said, this should really be configurable without recompiling the 
> init system.

Amen to that.

It's crazy to have these things hard-coded into a C program.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
virt-df lists disk usage of guests without needing to install any
software inside the virtual machine.  Supports Linux and Windows.
http://et.redhat.com/~rjones/virt-df/
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel


Re: noexec on /dev/shm

2010-12-14 Thread Matthew Miller
On Mon, Dec 13, 2010 at 11:57:51PM +0100, Dominik 'Rathann' Mierzejewski wrote:
> > the MS_NOEXEC flags is in private systemd fstab, see
> > systemd/src/mount-setup.c:
> You're not kidding. Could the author of this code (I'm guessing...
> Lennart?) please explain this extremely bright idea of hard-coding
> what should be admin-configurable?

That's not a very constructive wording. Filing a bug showing your use-case
would be helpful.

-- 
Matthew Miller 
Senior Systems Architect -- Instructional & Research Computing Services
Harvard School of Engineering & Applied Sciences
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel


rawhide report: 20101214 changes

2010-12-14 Thread Rawhide Report
Compose started at Tue Dec 14 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.fc12.x86_64 requires libdotconf-1.0.so.0()(64bit)
db4o-7.4-2.fc13.x86_64 requires mono(Mono.GetOptions) = 0:2.0.0.0
dh-make-0.55-2.fc15.noarch requires debhelper
eog-plugins-2.30.0-2.fc14.x86_64 requires libgdata.so.7()(64bit)
esmtp-1.0-6.fc12.x86_64 requires libesmtp.so.5()(64bit)
f-spot-0.8.0-5.fc15.x86_64 requires mono(FlickrNet) = 0:2.2.0.0
gedit-vala-0.10.2-2.fc15.i686 requires libvala-0.10.so.0
gedit-vala-0.10.2-2.fc15.x86_64 requires libvala-0.10.so.0()(64bit)
1:gnome-bluetooth-moblin-2.91.2-1.fc15.x86_64 requires 
libmoblin-panel.so.0()(64bit)
1:gnome-games-extra-2.31.91.1-1.fc15.x86_64 requires 
libclutter-gtk-0.10.so.0()(64bit)
gnome-gmail-notifier-0.10.1-1.fc14.x86_64 requires 
libnotify.so.1()(64bit)
gnome-phone-manager-0.65-8.fc14.x86_64 requires libgnokii.so.5()(64bit)
gnome-phone-manager-telepathy-0.65-8.fc14.x86_64 requires 
libgnokii.so.5()(64bit)
gnome-pilot-eds-2.32.0-1.fc14.x86_64 requires 
libcamel-1.2.so.19()(64bit)
gnome-python2-brasero-2.32.0-1.fc14.x86_64 requires 
libbrasero-burn.so.1()(64bit)
gnome-python2-brasero-2.32.0-1.fc14.x86_64 requires 
libbrasero-media.so.1()(64bit)
gnome-python2-evince-2.32.0-1.fc14.x86_64 requires 
libevdocument.so.3()(64bit)
gnome-python2-evince-2.32.0-1.fc14.x86_64 requires 
libevview.so.3()(64bit)
gnome-python2-evolution-2.32.0-1.fc14.x86_64 requires 
libcamel-1.2.so.19()(64bit)
gnome-python2-totem-2.32.0-1.fc14.x86_64 requires 
libgnome-media-profiles.so.0()(64bit)
gnome-rdp-0.2.3-6.fc12.x86_64 requires mono(Mono.Data.SqliteClient) = 
0:2.0.0.0
gpx-viewer-0.2.0-3.fc14.x86_64 requires libchamplain-0.6.so.0()(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 
libchamplain-gtk-0.6.so.0()(64bit)
gshutdown-0.2-6.fc12.x86_64 requires libnotify.so.1()(64bit)
gsql-0.2.1-4.fc12.i686 requires libnotify.so.1
gsql-0.2.1-4.fc12.x86_64 requires libnotify.so.1()(64bit)
gyachi-plugin-libnotify-1.2.10-3.fc14.x86_64 requires 
libnotify.so.1()(64bit)
hornsey-1.5.2-0.3.fc15.x86_64 requires libnotify.so.1()(64bit)
hornsey-1.5.2-0.3.fc15.x86_64 requires libclutter-gtk-0.10.so.0()(64bit)
ibus-fbterm-0.9.1-10.fc15.x86_64 requires libibus.so.2()(64bit)
intellij-idea-9.0.1.94.399-12.fc15.x86_64 requires commons-collections
java-gnome-4.0.16-3.fc14.x86_64 requires libnotify.so.1()(64bit)
libnotifymm-0.6.1-8.fc14.i686 requires libnotify.so.1
libnotifymm-0.6.1-8.fc14.x86_64 requires libnotify.so.1()(64bit)
log4net-1.2.10-13.fc13.x86_64 requires mono(System) = 0:1.0.5000.0
log4net-1.2.10-13.fc13.x86_64 requires mono(System.Data) = 0:1.0.5000.0
log4net-1.2.10-13.fc13.x86_64 requires mono(mscorlib) = 0:1.0.5000.0
log4net-1.2.10-13.fc13.x86_64 requires mono(System.Xml) = 0:1.0.5000.0
log4net-1.2.10-13.fc13.x86_64 requires mono(System.Web) = 0:1.0.5000.0
moblin-panel-media-0.0.8-0.2.fc13.x86_64 requires 
libmoblin-panel.so.0()(64bit)
mono-ndoc-1.3.1-8.fc13.x86_64 requires mono(System.Drawing) = 
0:1.0.5000.0
mono-ndoc-1.3.1-8.fc13.x86_64 requires mono(System.Windows.Forms) = 
0:1.0.5000.0
mono-ndoc-1.3.1-8.fc13.x86_64 requires mono(System) = 0:1.0.5000.0
mono-ndoc-1.3.1-8.fc13.x86_64 requires mono(mscorlib) = 0:1.0.5000.0
mono-ndoc-1.3.1-8.fc13.x86_64 requires mono(System.Xml) = 0:1.0.5000.0
1:nant-0.85-34.fc13.x86_64 requires mono(ICSharpCode.SharpZipLib) = 
0:0.84.0.0
nntpgrab-gui-0.6.90-3.fc15.x86_64 requires libnotify.so.1()(64bit)
padevchooser-0.9.4-0.11.svn20070925.fc13.x86_64 requires 
libnotify.so.1()(64bit)
pidgin-gfire-0.9.2-2.fc15.x86_64 requires libnotify.so.1()(64bit)
qtgpsc-0.2.3-6.fc12.x86_64 requires libgps.so.18()(64bit)
spacewalk-backend-tools-1.2.74-2.fc15.noarch requires spacewalk-admin 
>= 0:0.1.1-0
sunbird-1.0-0.33.b2pre.fc15.x86_64 requires libnotify.so.1()(64bit)
valide-0.7.0-7.20100923bzr557.fc15.i686 requires libvala-0.10.so.0
valide-0.7.0-7.20100923bzr557.fc15.x86_64 requires 
libvala-0.10.so.0()(64bit)



Broken deps for i386
--
beagle-0.3.9-19.fc14.i686 requires libmono.so.0
beagle-0.3.9-19.fc14.i686 requires libmono.so.0(VER_1)
cpm-0.23-0.3.beta.fc12.i686 requires libdotconf-1.0.so.0
db4o-7.4-2.fc13.i686 requires mono(Mono.GetOptions) = 0:2.0.0.0
dh-make-0.55-2.fc15.noarch 

Re: help with build failure

2010-12-14 Thread Mamoru Tasaka
gia...@gmail.com wrote, at 12/14/2010 06:50 AM +9:00:
> Hi all,
> I'm trying to fix the F15 build failure for gpointing-device-settings
> reported here:
> https://bugzilla.redhat.com/show_bug.cgi?id=660864
>
> and I'd need some help to understand what's going on. The main issue
> was related to a newer gtk version, this one is now fixed.
>
> The other one is trickier (at least for me), as the package which is
> building fine in mock for F14, fails with something like:
>
> /usr/bin/ld: .libs/libpointing_device_la-gsd-pointing-device-plugin.o:
> relocation R_386_GOTOFF against undefined symbol
> `gsd_mouse_extension_plugin_class_finalize' can not be used when
> making a shared object
> /usr/bin/ld: final link failed: Bad value
> collect2: ld returned 1 exit status
>
> scratch build here:
> http://koji.fedoraproject.org/koji/getfile?taskID=2661197&name=build.log
>
> Can anyone help me fix it?
>

This is due to this change in gnome-settings-daemon:
http://git.gnome.org/browse/gnome-settings-daemon/commit/?id=0dda56c4462e070

It seems at least you have to define
gsd_mouse_extension_plugin_class_finalize(GsdMouseExtensionPluginClass *klass)
in modules/gnome-settings-daemon-plugins/gsd-pointing-device-plugin.c

Regards,
Mamoru
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel


Nonreponsive maintainer for atop: Kairo Francisco de Araujo

2010-12-14 Thread Gilboa Davara
Hello all,

Following the nonresponsive package maintainers policy, a new version of
atop has been released a couple of months ago but never made it into
Fedora, bug report filed (+patch, [1]) 3 weeks ago.

Other open bug listed below. [2,3]

- Gilboa
[1] https://bugzilla.redhat.com/show_bug.cgi?id=657207
[2] https://bugzilla.redhat.com/show_bug.cgi?id=609124
[3] https://bugzilla.redhat.com/show_bug.cgi?id=659629


-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel


Re: RetraceServer security [Re: abrt wishlist]

2010-12-14 Thread Jiri Moskovcak
On 12/14/2010 03:51 AM, Jan Kratochvil wrote:
> On Thu, 09 Dec 2010 17:10:49 +0100, David Malcolm wrote:
>> Another gratuitous me too, see:
>>https://fedoraproject.org/wiki/Talk:Features/RetraceServer
>
> Detailed description:
> [...] User sends the coredump [...]
>
> Do you intend to make it default for Fedora?
>

- not decided yet, but I'm thinking about something user friendly like 
dialog saying:

How do you want to generate the backtrace?
1. Locally (will download XY MB of debuginfo and you need gdb and etc..)
2. I want to use the RS (WARNING!!: will upload the core file which may 
contain a sensitive data, but provides a better backtrace)
3. I need to ask my older brother, so cancel the reporting ...


> So far I thought it is not acceptable and in many cases my request in BZ for
> a core dump was refused by a user due to security concerns.
>

- some people won't send it some will.. When I can't reproduce the bug 
and user doesn't want to send me the core, then sorry -> CLOSED 
INSUFF_INFO what else can you do?

>
> OTOH the system binaries are already provided by the Fedora project and if the
> retrace server infrastructure has the same security as Koji servers the
> security level stays the same.
>

- exactly if we want to get user's private data there is many easier 
ways then to build a server and write a special app for it...

But the core definitely won't be uploaded without making sure that user 
understands what he is about to upload, as we don't want to get under 
the same critic as one of the well known operating system developer :)

Jirka
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel


Re: HEADS UP! Ohloh Fedora repositories

2010-12-14 Thread Peter Lemenkov
Hello!

2010/12/14 Mat Booth :

> Sorry for the threadcromancy, but I just checked my Ohloh profile
> today and it hasn't registered any of my commits since we switched
> from CVS to Git. Is Ohloh still crushed under the weight of our mighty
> distro?

Yes, it still suffers from its architectural shortcomings. This is a
known issue, and new Ohloh team is working on it. Unfortunately it
seems that they have a lot of other (more urgent) tasks, so I wouldn't
expect
resolution of this problem in the nearest future.

-- 
With best regards, Peter Lemenkov.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel