Re: noexec on /dev/shm
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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)
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
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
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
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
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
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
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
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
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
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
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
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
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
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.
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
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
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
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
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
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
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
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
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
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
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
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?
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?
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
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
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
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
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
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
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
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
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
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?
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
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?
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?
> "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?
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
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
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
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
> - 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
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
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
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
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
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
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
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
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]
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
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