Re: Inter-WG coordination: Stable application runtimes
tor 2014-01-09 klockan 20:30 -0800 skrev Andrew Lutomirski: It would be nice, at least, if there was a clean way for these stacks to be tracked and, if needed, uninstalled. Some of these things install into /usr, which is a giant mess. (Pip, the one I use the most, doesn't do that IIRC, but it's still annoying that, if I install a package with pip, that package *automatically*, *without prompting*, and (I think) without verifying signatures or any sort, will pull in dependencies from pypi that could be satisfied by yum. If I then install the yum version, I end up in a weird state. There are systems like virtualenv (python) and local::env (perl) that mirror the base distro in a separate directory and then let the user install modules and apps on top, without touching the distro-controlled directories. This is in my opinion the only sane way to use pip and CPAN, but in can be improved: What happens if you add/remove/update a distro package after creating a virtualenv? Add and update might be ok, but remove will quite likely break the app. What about apps that use more than one stack? Can a unified tool that mirror the whole distro be created? It might be as simple as combining the existing tools for each stack. Sane defaults for directories: I've found that when using virtualenv to install a web app, SELinux will complain less if you put the base directory somewhere in /var/www. What is the right place to put these stacks? Codify this in the packaging and in SELinux so that it just works. I'd like some way (maybe using something like mock) to manage these things in a somewhat sandboxed way. Docker is trying to do this, but I think it's the wrong approach for a lot of use cases, and its nowhere near ready for prime time. But once you've considered every aspect (for example my points above), you've basically reinvented Docker anyway. /Alexander -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F20 System Wide Change: No Default Sendmail
mån 2013-07-22 klockan 18:36 +0200 skrev Lennart Poettering: Despite that I am pretty sure that most of the stuff we currently mail (like the log output of cron jobs) simply makes no sense as mail, and should much rather be treated exactly like all other log output. There's nothing special really about cron that would make it so much better suitable for sending out its logs per mail, rather then just log them. Yeah, as a sysadmin I'm mostly annoyed by services that send mail and expect someone to have time to read them. Give me a current status that can be monitored as appropriate (desktop notifications, Nagios etc) and logs so I can go back and see what went wrong. Also, I think people who are new to this stuff are much more likely to look for logs than for mail (what, computers can have mail on them?) when they're trying to figure out what's happening. It is however a bit scary if the behavior of cron changes when someone installs an MTA. I think -s should be the default, but MAILTO= should have precedence over -s. /Alexander -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: another upgrade, another disaster
fre 2012-06-01 klockan 09:48 -0700 skrev Adam Williamson: Frankly, I'd prefer it if we more strongly recommended that people do DVD/netinst upgrades. That path is less complex than preupgrade and involves fewer moving parts; it's easier to test and easier to fix and more likely, in general, to be working at any given point. Please no. Once Fedora is installed it really ought to be able to upgrade itself without needing new boot media twice a year, that's just not user friendly. It's also much safer to first download everything and then start the RPM transaction. (IIUC a normal Anaconda upgrade will download packages during the upgrade.) /Alexander -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: While we're talking about RPM dependencies ...
fre 2012-04-06 klockan 10:17 +0100 skrev Richard W.M. Jones: AIUI you don't need to bump the soname when you add a new function, only if you incompatibly change an existing function or struct. To clarify (if I understand correctly) the minor version should be incremented in this case, by incrementing current and age in the libtool versioning, but it'd still be libusbredirhost.so.1 so it wouldn't matter with regards to dependencies. libfoo.so.major.minor.revision corresponds to libtool current:revision:age = major+minor:revision:minor. http://www.gnu.org/software/libtool/manual/html_node/Updating-version-info.html#Updating-version-info /Alexander -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Torvalds:requiring root password for mundane things is moronic
ons 2012-02-29 klockan 17:51 -0500 skrev Simo Sorce: That said I understand your pain and the realize the current solution is not ideal for the casual user. Maybe we should have 2 security profiles (lax and strict) that you can choose at install time so that people can choose what they like best. I'd call them single user and multi user. On a single user machine is makes sense to try to protect the user from themself, but you do that by carefully selecting defaults and explaining what the issues are with connecting to a non-trusted network, for example. No by asking for a password at random points. On a multi user machine it makes sense to protect users from each other and prevent one user from doing things that may cause problems for other users, like modifying the IP routing or the host-wide printer config. You really need an extra password or a dedicated admin account to elevate to, then. /Alexander -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: serious conflicts between python pks installed via yum vs pip
fre 2012-02-10 klockan 11:38 -0500 skrev Neal Becker: 80 wrote: Never use pip outside an isolated environment (use virtualenv) H. Really? This is the only answer? Does it help if we add that virtualenv is really useful? You can use it to install a completely new copy of an application, including upgraded dependencies, and then switch to that new virtualenv atomically and reversibly. /Alexander -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Need Little IT advice Here...
On fre, 2011-08-12 at 00:05 -0700, T.C. Hollingsworth wrote: Why not keep a known good home directory on hand, and replace it on logout? Though you still have the user's files in other locations on disk. It'd be better to just create a new user for each login. Or xguest, or LVM or btrfs snapshots. /abo -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Adding ~/.local/bin to default PATH
On ons, 2011-07-27 at 21:59 +0200, Marc-André Lureau wrote: I don't understand the security risks. If something is allowed to write to ~/.local/bin (or ~/bin etc..), then surely it's able to read elsewhere or do something else nasty. Could someone detail it? Also, consider that the attacker would need to be able to set the mode of the file to executable, which is not required for .bash*. Since it's at the end of PATH, they would have to install a binary that doesn't exist in /usr/bin already and then trick the user to run it at some later point. Too complicated when there are so many much easier attack points in the home directory. Oh, and why should .bashrc be hidden? Some attacker might hide code there! (See where I'm getting here?) The security argument is _bogus_ and splitting hairs in any case. Btw, if it's wrong to promote ~/.local/bin, then why should ~/bin be there by default? /Alexander -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd: Is it wrong?
tis 2011-07-12 klockan 06:29 + skrev JB: Regarding your statement on Parallelism. Let's consider these two ExecStartPre with 'exec': Is that still considered sequential execution, or parallel execution and a violation of the previous principle ? Starting SysV scripts from ExecStartPre is (I'm pretty sure) not how the systemd authors intended unit files to be written. You can't really talk about principles when you go outside of the system's design. Actually, this question has a general ramification, as it applies to any of Pre, regular, and Post sequential execution principle within unit file. What is the meaning and purpose of serial execution within systemd ? - mechanical submit for execution, wait for return code, iterate - or more involved submit for execution, wait for command (job) completion, presumably to avoid ... parallelism and its potential side effects like any conflicts, races, etc; with return code, iterate Waiting for return code and waiting for command completion are pretty much the same thing. /abo -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd: Is it wrong?
Please just stop trying to explicitly abuse the system and instead figure out the cleanest way to solve whatever problem you're trying to solve. /abo -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd: Is it wrong?
mån 2011-07-11 klockan 12:55 -0400 skrev Steve Dickson: * The variables read out of the EnvironmentFile are *always* character strings which means set LOCKD_TCPPORT=234 is no longer possible. Losing that ability to set variable to integer values seem to like a giant step backwards. The default value is (empty string) so you need to handle that case. (The SysV script has an if clause for exactly this purpose.) It looks like you can have multiple EnvironmentFile (or just use Environment=), which allows you to have one file with the default values and one config file where they can be overridden. Or you can modify the unit file to handle the empty variable in some other way. Say, by branching out into a shell script which only calls sysctl if the variable is set. Or by creating a special command which does about the same. Or by moving it into rpc.statd. /abo -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd: Is it wrong?
Hi, I'm a sysadmin who likes when things change for the better. I also like systemd. Sure, I read this list and stay informed, but my employer is a RHEL subscriber so for non-hobby purposes I only need to deal with change every few years, which is manageable. (SSSD is a problem of this kind in RHEL6, but if you actually look at it you see that it solves real issues and has the potential to solve even more. The alternative is stagnation.) That said, I'd rather have the old SysV scripts than unit files created in anger, because yes, the latter will be ugly and annoying to use. But the goal has to be a set of nice and clean unit files, so please try to work on that? I've yet to see any sound technical argument about why it couldn't be done. I'm sceptical of Jóhann's FOO=foo=4711 solution. (Nothing to do with integers vs. strings, btw, non-set shell variables has always had a default value of the empty string.) Perhaps a better approach is either to use a little helper script that calls sysctl and modprobe if the variables are set (exactly what the SysV script does) or even better, move this logic into rpc.statd itself (reimplement in C). Maybe if you move it into rpc.statd then module autoloading becomes possible too, which simplifies things further? To me, the thing about conditionally starting the GSSAPI stuff sounds like a job for socket activation, but that's just a guess. /abo -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Trusted Boot in Fedora
fre 2011-06-24 klockan 10:01 +0100 skrev Camilo Mesias: I am still struggling to see real applications for this. I don't know how a networked system using the technology could be differentiated from an (insecure) software simulation of the same from a remote viewer's perspective. Add another requirement: The remote viewer has previously had the opportunity to locally/physically inspect the device and determine what public key it has generated. /abo -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [FHS] helper scripts location
mån 2011-06-13 klockan 11:52 -0400 skrev Simo Sorce:
On Mon, 2011-06-13 at 17:41 +0200, Miloslav Trmač wrote:
On Mon, Jun 13, 2011 at 5:36 PM, Lennart Poettering
mzerq...@0pointer.de wrote:
That is not really how it is. /lib is for arch-dependent stuff including
the libraries of the primary arch. Libraries for secondary archs are
then put in /usr/lib{64,arch}/.
On x86_64 the 64-bit arch is primary and the 32-bit arch is secondary.
Surely the 32-bit files don't belong to /usr/lib64?
Don't think of it as primary and secondary. Think of it as the arch
that got its hands on /usr/lib first and the arch that had to make do
with another directory for its conflicting files.
I thinkLennart is saying that on a 64 bit system they would have to go
to /usr/lib32
I don't think that's what Lennart means...
The difference between libraries and binaries is that with libraries you
sometimes need both the primary and the secondary, but with binaries you
only need one, so those binaries can go in the same directory /usr/lib
regardless of their arch. (Just like there's no bin64.)
To put it another way:
Sure, /usr/libexec could be removed, but there's no need to then split
its content into /usr/lib and /usr/lib64. Only use lib64 in the cases
where there would be a conflict between the two arches.
/abo
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F15 / VirtualBox
tor 2011-06-09 klockan 18:37 -0400 skrev Dave Jones: Why are people choosing it over other solutions, and what can we change in qemu/kvm to get users using that instead ? Resurrect kqemu? No, not gonna happen. There are still usable CPUs out there, even 64-bit ones, that KVM won't run on. There's Xen, but that comes with its own set of gotchas. /abo -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: World IPv6 Day Problems
ons 2011-06-08 klockan 15:07 -0600 skrev Trever L. Adams: After restarting from rc.local wlan0 has fe80, but not 2001 address assigned. I've never used the v6 support in libvirt, so I'm guessing here, but wlan0 is the physical interface on the host that you're running radvd on, right? That would pick up router advertisements from the router in your wireless LAN, if you have one. I guess if radvd is bound to virbr0 then that interface would pick up an address from your prefix though. What is the output of ip -6 addr ? /abo -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Installing bash-completion by default in F-16
tis 2011-06-07 klockan 13:50 -0400 skrev Bill Nottingham: Group updates are not a part of any normal update process (either via yum, or anaconda.) yum upgrade is not a normal update process but it does include doing yum groupupdate Base. See http://fedoraproject.org/wiki/YumUpgradeFaq /abo -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Installing bash-completion by default in F-16
lör 2011-06-04 klockan 13:38 +0200 skrev Reindl Harald: no - i am using bash-completion since years on all machines but i do not like making default-install bigger as really needed let the users install what THEY think they need and do not go the apple-way deciding what is good for users I'm in favour of installing bash-completion by default because it's not really about adding functionality but rather about working around a problem with bash: It's silly and wrong that tab completion only works on filenames. ssh TAB - do you want to ssh to Desktop or to Documents? Consider a hypothetical bash-uncompletion which just blacklists tab completion in those cases where it doesn't make sense but never adds any new completion sources. Should that be installed by default? It would be rather small and light. /abo -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Installing bash-completion by default in F-16
sön 2011-06-05 klockan 15:30 +0200 skrev drago01: 2011/6/5 Alexander Boström a...@root.snowtree.se: [...] Consider a hypothetical bash-uncompletion which just blacklists tab completion in those cases where it doesn't make sense but never adds any new completion sources. Should that be installed by default? It would be rather small and light. That's makes no sense at all ... as if saving a couple of hundred of kb helps anything. Any argument based on size here is rather pointless. I agree. bash-completion is small enough. Even if all it did was to get rid of bogus completions it would still offer a better user experience at a small cost so it should be in the default package set. Now it does more than that. /abo -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: UID_MIN GID_MIN changed
tor 2011-05-26 klockan 08:52 -0400 skrev Simo Sorce: On Thu, 2011-05-26 at 07:39 +0200, Alexander Boström wrote: Personally I think UIDs and their relation to user accounts should be treated as host-local. I also want a pony. It would be nice, but then there is NFS ... Oh yes I'm well aware. (Not sure about CIFS and various other network filesystems but at least AFS prefers a global UID space.) There's also the problem with roaming UID-capable filesystems, like ext4 on a USB drive. I really think all of those should have some sort of mapping between the filesystem's and LDAP server's internal user id and the host-local UID space. But yes, ponies. My point is that until the above exists admins really do need to be prepared to deal with UID collisions caused by changes in the OS or by switching between OS:es or machines. Therefore it is ok for the OS to extend the reserved range from 500 to 1000. (It's a 31-bit range for crying out loud, there's plenty of room.) /abo -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: 9base in Fedora?
ons 2011-05-25 klockan 19:14 +0100 skrev Matthew Garrett: If they're in their path, other utilities are going to misbehave in ways that will be difficult to debug. The user could add the directory to PATH without exporting PATH to subprocesses, or they could use the shell's alias functionality instead. Then it will only be used when they type the command name in their own shell. Actually, the user must make sure to do this after /etc/profile.d/* is sourced since those might break. I don't know in what way 9base is useful but I think the relevant questions here are: Would it be ok for a package to 1. Install a number of prefixed binaries in /usr/bin/ 2. Install a number of unprefixed binaries in /usr/lib/pkgname/bin/ 3. Install some files in /usr/share/pkgname/profile.d/ (or something) which are meant to be sourced in the user's shell ? Is /usr/lib/pkgname/bin ok for both arch in multilib? Or does it have to be /usr/lib64 on x86_64 for some reason? Btw, using shell aliases means that it won't even need to install anything in /usr/lib/*/bin. If something can be packaged in a way that will not break things even if the package is installed and won't increase the size of a minimal install through dependency creep then let them. :) /abo -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: UID_MIN GID_MIN changed
ons 2011-05-25 klockan 12:37 -0500 skrev Dennis Gilmore: another issue that i thought of was existing ldap/nis systems that allocate regular users in the 500-1000 range when installing or upgrading if they use policies that probit system accounts from logging in will have users unable to login. As someone who admins such an LDAP setup I think the sooner the change is made the better. (If it had been changed long ago then it wouldn't have been a problem now.) Personally I think UIDs and their relation to user accounts should be treated as host-local. I also want a pony. /abo -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: 9base in Fedora?
fre 2011-05-20 klockan 14:17 +0200 skrev Petr Sabata:
#1, aka the Gentoo way
Gentoo installs its 9base package into /usr/plan9, basically not touching
9base files at all. This collides with FHS and therefore would require an
exception in Packaging Guidelines.
About /usr, FHS has this to say:
Large software packages must not use a direct subdirectory under
the /usr hierarchy.
http://www.pathname.com/fhs/pub/fhs-2.3.html#THEUSRHIERARCHY
#2, aka the Debian way
Debian installs its 9base package into /usr/lib. Well, most of it. They
also prefix all the manpages with 'plan9-', not the binaries, though.
This placement (provided we use %{_libdir}) introduces issues for Plan
9 rc shell scripts and their shebangs.
/usr/lib/9base/bin, specifically.
About /usr/lib in FHS:
Applications may use a single subdirectory under /usr/lib.
Well that sounds just like what we need.
But there's also this bit:
/usr/lib includes object files, libraries, and internal binaries
that are not intended to be executed directly by users or shell
scripts.
Which doesn't work in this case.
http://www.pathname.com/fhs/pub/fhs-2.3.html#USRLIBLIBRARIESFORPROGRAMMINGANDPA
#3, aka the Fedora way?
Should we do this in some other way?
Fedora + FHS doesn't seem to allow for any decent way of installing
multiple user-oriented binaries with the same name. I suggest adding a
prefix 9 or 9base- or similar to all the binaries and man pages. You
may even make /usr/bin/9base-foo a symlink into
/usr/lib/9base/bin/foo so the user can still add the other directory
to their PATH and have the short names.
If the prefix solution is not acceptable then #2 is the best alternative
because it's a smaller FHS violation and doesn't clutter /usr.
/abo
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS-UP] util-linux[-ng] and mtab
ons 2011-01-19 klockan 18:35 +0100 skrev Karel Zak: The util-linux v2.19-rc1 contains support for systems without /etc/mtab (the file is replaced with symlink to /proc/mounts). Wasn't that supposed to be /proc/self/mounts? /Alexander -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS-UP] util-linux[-ng] and mtab
ons 2011-01-19 klockan 21:12 +0100 skrev Alexander Boström: Wasn't that supposed to be /proc/self/mounts? Nevermind, /proc/mounts is a symlink so it doesn't matter. /Alexander -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fast Light Tool Kit
lör 2010-10-30 klockan 17:05 -0400 skrev Eric Sparks Christensen: The source is a single file with no readme and I'm not exactly sure how to package the software. Probably: cc -o foo foo.c $(fltk-config --cflags --ldflags) /abo -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: repos.fedorapeople.org
fre 2010-07-30 klockan 16:04 -0500 skrev Mike McGrath: I'm happy to announce the availability of repos.fedorapeople.org. Intended for non-transient package hosting, it's a good central location to store packages that users might find interesting. Cool! Clicking on -release rpms in the browser is probably the most convenient way for users to add repos. (Should it be convenient?) This script can be used to generate them: http://abo.fedorapeople.org/tmp/fedorapeople-repo-releaserpm.sh The third argument Fedora release number would be the oldest release you intend to support in the repo as it will require system-release = N. The included .repo file is independent of the release. /Alexander -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Testing Fedora? Please enable SELinux if you can
fre 2010-07-30 klockan 12:51 +0530 skrev Rahul Sundaram: On 07/30/2010 12:47 PM, Camilo Mesias wrote: The use cases in case anyone's interested: Install Picasa3 (which uses its own wine version*) It's winelib, not wine, right? *Google recommends turning off SELinux These are proprietary software outside the Fedora repository and cannot be fixed by anyone except the vendor. However there is a workaround: restorecon -R -v /opt If a non-SELinux aware application installs itself in /opt, shouldn't it get the default labels by, eh, default? /Alexander -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Question regarding dist-git aesthetics with branches
ons 2010-07-21 klockan 11:48 -0700 skrev Jesse Keating: The other option is to make the dist translation change on the other branches too, so that future f12 and f13 builds have a dist of .f12 and .f13 I was just going to suggest this. f1x means built from git, fc1x means cvs. /Alexander -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS-UP] systemd for F14 - the next steps
tor 2010-07-22 klockan 18:48 +0200 skrev Miloslav Trmač: I don't know whether this currently happens with Fedora, but it is not at all irrelevant and systemd could indeed make the situation much worse. A typical problem in the past has been that starting dbus includes looking at users and groups which means you need ldap and network but oh wait networkmanager starts after dbus. This can cause _really_ long timeouts during boot, basically a hang. (I might have gotten some detail wrong but something like the above can happen. There are workarounds and also SSSD might be better than nss_ldap here.) So what I'm saying is, we already have this problem and it already has to be dealt with manually by booting in single user mode or press I at the right point during boot. Possibly systemd will actually help, as it might make it possible that at least the text mode logins appear even if there's a deadlock starting some deamons. Can systemd track dependecies (deamon foo connects to socket for deamon bar) and detect and print error messages about deadlocks? Maybe even break the loops, causing some deamons to just fail to start? /Alexander -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS-UP] systemd for F14 - the next steps
tor 2010-07-22 klockan 15:12 -0400 skrev Simo Sorce: The nss_sss and pam_sss clients know to immediately give up if the sockets are not there because that means that sssd is not up yet. If I were to use socket activation instead that service would bring sssd up unnecessarily early, before the network is up. This in turn will cause sssd to go in offline mode and have a 30 sec delay before it Now this will probably mitigated by the fact that we monitor network interfaces in newer versions and will try to get online earlier if an interface suddenly appears, but I hope you get the point. But this means that SSSD + socket activation would work quite well, pretty much the same was as it does as a standalone deamon, right? /Alexander -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS-UP] The systemd unit files I'll post
tor 2010-07-15 klockan 08:58 +0200 skrev Till Maas: How are the /etc/sysconfig/service files now used? E.g. on F12 ntpd drops privs to ntp:ntp according to /etc/sysconfing/ntpd, but ntpd.service file seems not to do something like this. So how about this: If /etc/sysconfig/service exists and contains any line that's not a comment, empty or only whitespace, then systemd should fall back to the SysV script. Then push updates to the packages containing the sysconfig files and start scripts such that the variables are commented out in the sysconfig file and the default values are set in the start script instead, before sourceing the sysconfig file. In case the admin modifies the sysconfig file and then updates the system to use systemd, that sysconfig file won't be replaced and will probably contain something that triggers systemd to fall back to SysV style there. /Alexander -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS-UP] systemd for F14 - the next steps
tor 2010-07-15 klockan 16:59 +0200 skrev Lennart Poettering: If I added inittab parsing support even when keeping native breaks legacy around, then inittab would matter only if the default.target symlink doesn't exist. Yeah, when saying keep compat you have to define exactly how to do that, which isn't always easy. I myself have written kickstart scripts that would need to be changed to deal with this but it's really rather trivial and I don't have any good alternative suggestion. But I do think the %postinstall script, if it's an install and not an update, should check the contents of inittab and set the symlink accordingly. Otherwise an upgrade to a new release might make the system start X when it didn't do that before, which would be bad. /Alexander -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS-UP] systemd for F14 - the next steps
ons 2010-07-14 klockan 23:53 +0200 skrev Lennart Poettering: On Wed, 14.07.10 15:42, Kevin Fenzi (ke...@scrye.com) wrote: Because you may have gdm installed and not wish to currently boot with it? I just tried systemd on a test machine here... it came up fine, but it started gdm, even though I normally don't want it to do so. But anaconda doesn't even offer you that functionality... Actually in kickstart scripts you can specify text which will run the installation in text mode and also make runlevel 3 the default. It's pretty useless though since if you do semi-interactive kickstarts (manual partitioning, everything else automatic for example) you want to install in graphical mode because text mode lacks some features but you still often want to boot into runlevel 3, so you end up specifying graphical instead of text and sed:ing inittab in the kickstart %post script. /Alexander -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS-UP] systemd for F14 - the next steps
ons 2010-07-14 klockan 20:54 +0200 skrev Lennart Poettering: On Wed, 14.07.10 13:31, Chris Adams (cmad...@hiwaay.net) wrote: Once upon a time, Lennart Poettering mzerq...@0pointer.de said: ExecStartPre=-/bin/mkdir -p /var/run/foo ; -/sbin/restorecon /var/run/foo Why would you ignore the exit code? If you can't make the directory and set the context, you shouldn't start the service. Well, dunno, maybe if SELinux is disabled via selinux=0 restorcon fails? Nah, please don't hide errors like that. It just makes things harder to debug. It could be done properly in a shell command but ExecStartPre probably doesn't take a shell command, just arguments for exec(), so you'd have to do ExecStartPre=bash -c 'blahblah'. Anyway, we're trying to avoid starting a shell for every daemon. The solution is to rewrite it in C code and have a RunDir=/var/run/foo option in the unit file which creates the directory and calls restorecon if necessary. For complicated cases where a shell command really is needed you can use the bash -c trick or put the command in a shell script file and just specify ExecStartPre=/usr/share/foo/daemon-startpre.sh. The default is of course to check all return values, i.e. you have to explicitly prefix the commands with - to ignore them. Is this feature really necessary? I think it would be best to avoid using it... /Alexander -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS-UP] systemd for F14 - the next steps
ons 2010-07-14 klockan 15:03 -0400 skrev Daniel J Walsh: BTW: restorecon exits silently if SELinux is disabled. Oh. Forget what I said then. I still think - is a nonfeature though. :) /Alexander -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: New Hatari version: need help
lör 2010-06-19 klockan 19:32 +0200 skrev Andrea Musuruane: I do not know how should I threat those internal libraries. How should I package them? Because upstream uses static libraries the dynamic versions cmake creates are not versioned. https://fedoraproject.org/wiki/Packaging:Guidelines#Rpath_for_Internal_Libraries /Alexander -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: JBoss stalled (was Re: status of some packages ??)
tor 2010-06-03 klockan 19:31 +0100 skrev Alex Hudson: On Thu, 2010-06-03 at 12:29 -0400, Tom spot Callaway wrote: On 06/03/2010 11:54 AM, Iain Arnell wrote: And slightly weird that it's okay for Red Hat to distribute it themselves, both commercially and as open source from jboss.org, but it's questionable for Fedora. I can't speak on what Red Hat does on a larger scale. I do know that it is important to me and Fedora that we do it properly, or not at all. If everyone else is distributing JBoss, though, that calls into question whether it's Fedora doing it properly. Worrying about a set of rights which are unwaivable seems on the face of it to be exhibiting an abundance of over-caution, and it seems particularly sad that Fedora is losing out having to refrain from distributing another Red Hat-sponsored project. It's not sad. It means the Fedora project will do the work to clean up a mess which most other don't even see. It's problematic, in a way, sure, but sad is really not the right word. /Alexander -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: suggestion: rescue boot extension
Ok, a mini-Fedora that lives entirely in a subdir of the boot partition, containing an application for managing grub.conf and other things. Things it should be able to do: * Manage those yum-integrated btrfs snapshots. * Download Fedora and other distro pxeboot and live images and stick them in grub.conf. * Change default boot menu entry, edit entries etc. Plus a terminal and various tools. /Alexander -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd (Was Re: tmpfs for strategic directories)
ons 2010-05-26 klockan 10:01 +0100 skrev James Findley:
It's really not at all uncommon for me to need to modify an init script.
There would be much rage if in order to do this I had to download the
SRPM, extract the init code, figure out what I needed to change, modify
it, recompile then install.
Various ways to deal with that:
1. Change the Exec=/usr/libexec/food to
ExecStart=/usr/local/sbin/foodwrapper
2. Add some hook support in the systemd config files.
3. Add support for switching specific services back to using the
initscript even when booting with systemd.
But on the other hand, shell scripts can be optimised too. Maybe the awk
call is redundant anyway? Maybe something like foo=${bar%.conf} would
be enough?
/Alexander
PS.
Someday I should go on a rampage and submit patches that add set -e;
set -o pipefail to the start of every shell script in the distro. Or
maybe not...
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Increase grub timeout
tis 2010-05-18 klockan 12:11 -0400 skrev Bill Nottingham: If you're really concerned about needing the timeouts when 'normal' bootup doesn't work, then why not write a patch that simply checks the time since last bootup (via mtime on grub.conf, or wahtever), and shows the menu if it's less than some predefined interval (say, 3 minutes?) How accurate time does grub have? It can read the clock via BIOS and get a +/- 13 hour accurate time, I guess. Maybe a clean shutdown could cause touch /boot/grub.good (or whatever). If grub.conf is newer than grub.good then add a few seconds to the timeout and show the menu? That avoids relying on the clock. One problem: Once you do whatever it was you needed to do in grub to get your system back, you need to go edit grub.conf right away before you reboot because you won't get another chance. /Alexander -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Increase grub timeout
My home server was running Fedora 10 and I tried to preupgrade it to F12, however the F12 kernel wouldn't work at all on this machine (it oopsed before even mounting the root) and no matter how frantically I pressed the arrow keys during boot I could never get into the GRUB menu and stop it from booting into F12 anaconda. Also, it had no CD drive and LiveUSB boot failed too. Luckily I had another harddrive laying around which had grub on it, so I could install and boot from that instead and return to F10. (The real fix turned out to be to upgrade the BIOS.) Long story short: There are situations where a grub menu is vital, like until you've successfully booted a new kernel. /Alexander -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: How this bug can come out of its dead-end? Any suggestions?!
sön 2010-05-09 klockan 11:22 +0430 skrev Hedayat Vatankhah: No, the problem is this: PackageKit does not know how to mount a removable media. Why do you even need to mount it? Removable media is of course automatically mounted when you insert it (if someone is logged in on the console). /Alexander -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: How this bug can come out of its dead-end? Any suggestions?!
sön 2010-05-09 klockan 18:54 +0200 skrev Kevin Kofler: Many of them have updates anyway. Use delta-RPMs (combining not the installed old version but the old version on the DVD with the downloaded drpm). /Alexander -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: use MALLOC_PERTURB_ ... or lose
ons 2010-05-05 klockan 17:30 +0200 skrev Jim Meyering: I propose (seriously, now) to add this to /etc/profile, or to some always-sourced file like /etc/profile.d/glibc.sh: # Enable glibc's malloc perturbing feature in Rawhide. # http://udrepper.livejournal.com/11429.html read _f _r _n _code_name /etc/redhat-release case $_code_name in *Rawhide*) export MALLOC_PERTURB_=$((RANDOM % 255 + 1)) ;; esac I think the file you're looking for is /etc/system-release or perhaps /etc/system-release-cpe. /Alexander -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Could someone, please, clarify situation with *-javadoc
lör 2010-05-08 klockan 00:56 +0200 skrev Guido Grazioli:
Someone would disagree with me; however i think any decision is taken on
that topic would be turned in a MUST (depend or not depend) for the sake
of coherency.
I can only think of rather far-fetched situations where such a
dependency would be needed, so I guess I agree...
This code snippet is telling me that specifying = specific_version
in BuildRequires: java-devel is optional, while it is mandatory in
Requires: java
I have no objections to that, but the ant and maven templates below
must be updated consistently with that.
Good call, fixed.
2- JavaDoc installation
The name of the subdirectory SHOULD be either %{name}
or %{name}-%{version} with a symlink %{name} pointing to it.
I would turn that in a MUST be either one or the other: different directory
naming should be a rare exception and SHOULD doesnt seem strong enough.
Hmm, I was too lazy to look for current counterexamples which might
provide guidance. Anyone have any? I changed it anyway.
You could drop the dependency on the main package for the manual too.
Fixed.
I also would write a more general %add_to_maven_depmap macro call, from:
%add_to_maven_depmap org.apache.maven %{name} %{version} JPP %{name}
to:
%add_to_maven_depmap [groupId] [artifactId] %{version}
JPP[/optional_subDir] [jarName]
Ok, added with a comment.
Finally, in the %files section:
%{_datadir}/maven2/poms/*
or
%{mavenpomdir}/*
Ok.
Hope that helps
Awesome!
/Alexander
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Could someone, please, clarify situation with *-javadoc
(changing lists) fre 2010-05-07 klockan 13:41 -0400 skrev Andrew Overholt: Hi, Sometimes *-javadoc sub-packages explicitly requires main package, and sometimes - not. I'm not a java-expert, so I don't know which is correct. I don't think it really matters. In some cases, sure, it would be nice to ensure that the package is around if someone is looking at the API documentation. Other times someone may only want to peruse the APIs without installing the implementation. Agreed. Those deps are now removed from the examples in https://fedoraproject.org/wiki/User:Abo/JavaPackagingDraftUpdate which I previously submitted as a proposed guideline update. (I hope I submitted it the right way...) Somehow I managed to not notice the java-devel list until recently so I think this is the first time I've mentioned the draft here. Please read and comment on it! The number of changes are growing... I should move it out of the User:Abo namespace so it doesn't look like a personal page. /Alexander -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: ABRT duplicate detection
lör 2010-04-24 klockan 10:37 +0200 skrev Christoph Höger: But if ABRT could detect duplicate crashes one could use this to display a workaround or even propose an update via packagekit. It could look in bodhi for packages which claim to fix the bug. Would you like to test a proposed fix for this problem? If the update is already installed or obsoleted then it just comments on the bug as usual. Also, a week later, if the same user logs in again: Have you experienced any problems with the update of package foo which was installed last Tuesday to fix the problem 'Foo borkborks on bar when baz'? /Alexander -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Shell commands like to OS/2 shell (or MS PowerShell)
tis 2010-04-20 klockan 01:51 +0300 skrev Slava Zanko: For example, all present utilites have sence just for guru's (ls, rm, fsck etc), but for novies it's hard to use. Is good idea to symlink'ing (shell aliasing) these and much more utilz to another names? The present utilities makes sense for gurus because they understand the history behind them and why the utilities have become what they are. But to create something that's easy for new users and that might be attractive to those of us that already know our way around the shell it wouldn't be enough to rename the commands. You'd need to dig deeper. For example you still have lots of obscure switches and options to consider. (Why is media.convert.video nothing at all like media.convert.audio.ogg?) And you have fun things like string quoting, forking processes, vectors (say, the difference between $* and $@), $IFS, error handling (did you know about set -e?) and so on... /Alexander -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Hard drive spec change
ons 2010-03-10 klockan 15:57 -0600 skrev Eric Sandeen: There has been a lot of work upstream on 4k sector support, and in general yes, we are ready. Problems can probably be expected in case the drive does not report its real block size to the software, though, like my WD15EARS (I think) or VMware's emulated SCSI drives. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: OT: fas-username vs. local username for fedora-cvs
mån 2010-03-01 klockan 20:13 +0100 skrev Till Maas: But I wonder, how do you access CVS without this? You shouldn't need it. What happens if you don't have it? CVS records the root location in the checked out copy, so you only need to supply a CVS root when doing cvs checkout and even then you don't need to set CVSROOT, you can just do cvs -d :ext:f...@bar:/baz checkout gazonk. The fedora-cvs tool does set CVSROOT but it could just as well use -d instead. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback)
lör 2010-02-27 klockan 15:26 +0200 skrev Ville Skyttä: there are several ways new installed packages can break existing systems, the combined results is that it is very much possible for newly introduced packages to automatically break existing systems. It could install a file in /etc/foo.d that causes something that loads /etc/foo.d/* to break. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
