Re: USRMOVE - get rid of /bin/ in PATH
On Qua, 2012-09-12 at 16:38 +0200, Reindl Harald wrote: would it be possible to get /bin rid of EVERY hardcoded path in the distribution? i have no single idea from where rpmbuild takes Requires: /bin/perl nor why ssh user@host /script.sh has still /bin/ before /usr/bin while there is no single config-file containing a PATH-change which would reflect this https://bugzilla.redhat.com/show_bug.cgi?id=856584 BTW : yum install /usr/lib/libc.so.6 No package /usr/lib/libc.so.6 available. but yum install /lib/libc.so.6 works and yum install /lib/libc.so No package /lib/libc.so available. but yum install usr/lib/libc.so works I have a question a little out of topic, sorry , why BuildRequires: glibc.i686 glibc-devel.i686 libstdc++.i686 gives me error in a mock build of x86_64 , what could I do to get this requirements ? Thanks, -- Sérgio M. B. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: USRMOVE - get rid of /bin/ in PATH
On Wed, 12 Sep 2012 18:35:08 +0100 Sérgio Basto ser...@serjux.com wrote: On Qua, 2012-09-12 at 16:38 +0200, Reindl Harald wrote: would it be possible to get /bin rid of EVERY hardcoded path in the distribution? i have no single idea from where rpmbuild takes Requires: /bin/perl nor why ssh user@host /script.sh has still /bin/ before /usr/bin while there is no single config-file containing a PATH-change which would reflect this https://bugzilla.redhat.com/show_bug.cgi?id=856584 The FPC discussed this briefly at todays meeting. They are going to talk to the rpm maintainer(s) and see if something can get fixed at that level. ...snip... I have a question a little out of topic, sorry , why BuildRequires: glibc.i686 glibc-devel.i686 libstdc++.i686 gives me error in a mock build of x86_64 , what could I do to get this requirements ? See: http://www.rpm.org/wiki/PackagerDocs/ArchDependencies and https://fedoraproject.org/wiki/PackagingDrafts/ArchSpecificRequires kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: UsrMove, /etc/shells, and rpm interpreter requires
On Tue, 2012-07-10 at 10:30 -0700, Toshio Kuratomi wrote: On Tue, Jul 10, 2012 at 06:12:45PM +0200, Harald Hoyer wrote: Am 10.07.2012 17:18, schrieb Orion Poplawski: Shouldn't that be /usr/ as well. Will it cause problems if it doesn't match with the /etc/passwd entry? yes, /etc/shells might be a problem... I would suggest: install the $shell in /usr/bin/$shell, Provide: /bin/$shell in the spec file and add both paths in /etc/shell or we patch chsh and the like? Adding both paths to /etc/shell sounds preferable to me. I can update the default /etc/shells shell paths to contain both paths in setup package, however, other shell packages are modifying it too, so it would be better to have some solution without need to involve dash, zsh, tcsh, ksh and maybe other shell maintainers and need them to update their packages because of the UsrMove changes. Any ideas? Greetings, Ondrej -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: UsrMove, /etc/shells, and rpm interpreter requires
On Wed, Jul 11, 2012 at 11:55:58AM +0200, Ondrej Vasik wrote: On Tue, 2012-07-10 at 10:30 -0700, Toshio Kuratomi wrote: On Tue, Jul 10, 2012 at 06:12:45PM +0200, Harald Hoyer wrote: Am 10.07.2012 17:18, schrieb Orion Poplawski: Shouldn't that be /usr/ as well. Will it cause problems if it doesn't match with the /etc/passwd entry? yes, /etc/shells might be a problem... I would suggest: install the $shell in /usr/bin/$shell, Provide: /bin/$shell in the spec file and add both paths in /etc/shell or we patch chsh and the like? Adding both paths to /etc/shell sounds preferable to me. I can update the default /etc/shells shell paths to contain both paths in setup package, however, other shell packages are modifying it too, so it would be better to have some solution without need to involve dash, zsh, tcsh, ksh and maybe other shell maintainers and need them to update their packages because of the UsrMove changes. Any ideas? /etc/shells.d :-? Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones libguestfs lets you edit virtual machines. Supports shell scripting, bindings from many languages. http://libguestfs.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: UsrMove, /etc/shells, and rpm interpreter requires
On Wed, 2012-07-11 at 11:55 +0200, Ondrej Vasik wrote: On Tue, 2012-07-10 at 10:30 -0700, Toshio Kuratomi wrote: On Tue, Jul 10, 2012 at 06:12:45PM +0200, Harald Hoyer wrote: Am 10.07.2012 17:18, schrieb Orion Poplawski: Shouldn't that be /usr/ as well. Will it cause problems if it doesn't match with the /etc/passwd entry? yes, /etc/shells might be a problem... I would suggest: install the $shell in /usr/bin/$shell, Provide: /bin/$shell in the spec file and add both paths in /etc/shell or we patch chsh and the like? Adding both paths to /etc/shell sounds preferable to me. I can update the default /etc/shells shell paths to contain both paths in setup package, however, other shell packages are modifying it too, so it would be better to have some solution without need to involve dash, zsh, tcsh, ksh and maybe other shell maintainers and need them to update their packages because of the UsrMove changes. Any ideas? I don't understand what's the problem. The /bin symlink pointing to /usr/bin is not going away any time soon so the shell in passwd entries and /etc/shells and in shebangs in scripts should stay at /bin/*sh. RPM packages can install in /usr/bin and provide /bin/*sh in the spec file. Requirements in other packages should stay at /bin/*sh. -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: UsrMove, /etc/shells, and rpm interpreter requires
Am 10.07.2012 17:18, schrieb Orion Poplawski: I just got the following: grib_api has broken dependencies in the rawhide tree: On x86_64: grib_api-1.9.16-3.fc18.x86_64 requires /usr/bin/ksh On i386: grib_api-1.9.16-3.fc18.i686 requires /usr/bin/ksh Please resolve this as soon as possible. after I decided to stop changing the path of /usr/bin/ksh to /bin/ksh in grib_api since I figured with UsrMove, /usr/bin/ksh should be the proper location. But then I see that ksh still installs in /bin. Before I file a bug against ksh I wanted to make sure that we do indeed want to move to /usr/bin. I see that bash is in /usr/bin, so I guess that's a yes. My other concern though is /etc/shells: # cat /etc/shells /bin/sh /bin/bash /sbin/nologin /bin/tcsh /bin/csh /bin/ksh /bin/zsh Shouldn't that be /usr/ as well. Will it cause problems if it doesn't match with the /etc/passwd entry? yes, /etc/shells might be a problem... I would suggest: install the $shell in /usr/bin/$shell, Provide: /bin/$shell in the spec file and add both paths in /etc/shell or we patch chsh and the like? Thoughts? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: UsrMove, /etc/shells, and rpm interpreter requires
On Tue, Jul 10, 2012 at 06:12:45PM +0200, Harald Hoyer wrote: Am 10.07.2012 17:18, schrieb Orion Poplawski: Shouldn't that be /usr/ as well. Will it cause problems if it doesn't match with the /etc/passwd entry? yes, /etc/shells might be a problem... I would suggest: install the $shell in /usr/bin/$shell, Provide: /bin/$shell in the spec file and add both paths in /etc/shell or we patch chsh and the like? Adding both paths to /etc/shell sounds preferable to me. -Toshio pgph2DrC3Xcxh.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: usrmove breaks on directory name conflict
On 04/23/2012 05:45 PM, Daniel Drake wrote: cp: cannot overwrite directory /mnt/sysimage/usr/bin.usrmove-new/mkdir with non-directory Something failed. Move back to the original state. Rebooted back into F16. It looks like the issue was that I had a directory at /usr/bin/mkdir/. No idea how, looks like it was from December. Probably my fault, but perhaps usrmove shouldn't fall over when facing this situation. If usrmove really reverted everything to its original state, it seems to me like a case of well-behaving error handling after encountering an unusual situation that cannot be resolved automatically and safely. Michal -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: usrmove breaks on directory name conflict
On Mon, 2012-04-23 at 09:45 -0600, Daniel Drake wrote: Hi, Last week I tried a preupgrade from F16 to F17 beta. When rebooting into the preupgrade environment, the upgrade failed in usrmove: Make a copy of /mnt/sysimage/usr/bin Merge the copy with /mnt/sysimage/bin cp: cannot overwrite directory /mnt/sysimage/usr/bin.usrmove-new/mkdir with non-directory Something failed. Move back to the original state. Rebooted back into F16. It looks like the issue was that I had a directory at /usr/bin/mkdir/. No idea how, looks like it was from December. Probably my fault, but perhaps usrmove shouldn't fall over when facing this situation. After removing that weird directory, I rebooted into preupgrade and it worked fine. Now running F17 beta. you should open a bug report in rhbz , with component preupgrade . Tks, -- Sérgio M. B. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: usrmove breaks on directory name conflict
Sérgio Basto wrote: you should open a bug report in rhbz , with component preupgrade . Isn't the usrmove script actually part of dracut? Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usrmove? - about the future
On 2/24/12 12:10 PM, Ville Skyttä wrote: On 2012-02-23 20:06, Jesse Keating wrote: Could you help me figure out why path completion with ~/ isn't working in fedpkg, but with full paths it is? I assume there is something wrong in the (contributed) bash completion file. https://fedorahosted.org/fedpkg/ticket/3 Thanks. That just further confirms that bash completion syntax is strange and complicated, and I know very little about it :) -- Jesse Keating Fedora -- Freedom² is a feature! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usrmove? - about the future
On 02/21/2012 06:31 PM, Doug Ledford wrote: it honors all the LSB dependency tags in the SysV init scripts, and my experience is that this is specifically where a number of the emulation startup bugs exists. What do you mean? That the LSB headers are incorrect too often? It's a problem, but that at least should not be too hard to fix. Furthermore, the design feature of not stopping anything that it didn't start seems to be more of a bug than a feature to me...it means that if an admin starts a service manually for whatever reason (debugging, want to see output, the systemd unit file won't allow the necessary interactive username and password prompt, etc.), then it won't get stopped properly on shutdown. Processes that are still around after stopping the services systemd knows about will get a SIGTERM and after 5 seconds a SIGKILL if they refuse to die. That is not a feature, that's just dumb. I disagree. Michal -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usrmove? - about the future
On 2/19/12 3:43 AM, Ville Skyttä wrote: On 2012-02-18 20:26, Rahul Sundaram wrote: On 02/18/2012 11:05 PM, Ville Skyttä wrote: You can get the completion to work according to that preference with for example yum install ./fooTAB - anything that looks like a filesystem path triggers filename-only completion, otherwise we do both filenames and repos. That's atleast understandable but there seems to be a big slowdown when doing rpmlint tab completion as well. Not sure why. rpmlint footab is much slower with bash-completion installed. The same thing applies to rpmlint. Anything that looks like a file path gets treated as a file path and is quick; otherwise we need to look up both files and rpmdb, and even though it has been getting better, the latter unfortunately isn't that quick. Could you help me figure out why path completion with ~/ isn't working in fedpkg, but with full paths it is? I assume there is something wrong in the (contributed) bash completion file. https://fedorahosted.org/fedpkg/browser/src/fedpkg.bash -- Help me fight child abuse: http://tinyurl.com/jlkcourage - jlk -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usrmove? - about the future
- Original Message - On 02/10/2012 06:32 PM, Adam Williamson wrote: systemd was explicitly written to be 100% sysv-compatible Mostly compatible, but not 100%. http://www.freedesktop.org/wiki/Software/systemd/Incompatibilities You're both joking, right? That isn't 100% compatible, it isn't mostly compatible, it's barely workable emulation that only works in generic cases and fails in all unusual circumstances that SysV used to work in, according to the page above anyway. And that's been my experience with it too. Plus it says that it honors all the LSB dependency tags in the SysV init scripts, and my experience is that this is specifically where a number of the emulation startup bugs exists. Furthermore, the design feature of not stopping anything that it didn't start seems to be more of a bug than a feature to me...it means that if an admin starts a service manually for whatever reason (debugging, want to see output, the systemd unit file won't allow the necessary interactive username and password prompt, etc.), then it won't get stopped properly on shutdown. That is not a feature, that's just dumb. -- Doug Ledford dledf...@redhat.com GPG KeyID: 0E572FDD http://people.redhat.com/dledford -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usrmove? - about the future
On Tue, 2012-02-21 at 12:31 -0500, Doug Ledford wrote: - Original Message - On 02/10/2012 06:32 PM, Adam Williamson wrote: systemd was explicitly written to be 100% sysv-compatible Mostly compatible, but not 100%. http://www.freedesktop.org/wiki/Software/systemd/Incompatibilities You're both joking, right? That isn't 100% compatible, it isn't mostly compatible, it's barely workable emulation that only works in generic cases and fails in all unusual circumstances that SysV used to work in, according to the page above anyway. And that's been my experience with it too. Plus it says that it honors all the LSB dependency tags in the SysV init scripts, and my experience is that this is specifically where a number of the emulation startup bugs exists. Furthermore, the design feature of not stopping anything that it didn't start seems to be more of a bug than a feature to me...it means that if an admin starts a service manually for whatever reason (debugging, want to see output, the systemd unit file won't allow the necessary interactive username and password prompt, etc.), then it won't get stopped properly on shutdown. That is not a feature, that's just dumb. Joking, no. Rather a lot of context was lost in the above. I was replying to Harald Reindl (I know, I know, that's always a mistake), who has often asserted that the systemd migration is 'broken by design' because we did not attempt to migrate every single sysv service in the entire distro to be systemd native within the timeframe of a single release. I pointed out that the migration process was always intended to be gradual, and systemd was specifically written with sysv compatibility in order to allow this. I agree that '100% sysv-compatible' was an inaccurate description, but chopping that statement out from the context of the discussion in which I wrote it makes it look much more egregiously so than it actually was. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usrmove? - about the future
On 2012-02-18 20:26, Rahul Sundaram wrote: On 02/18/2012 11:05 PM, Ville Skyttä wrote: You can get the completion to work according to that preference with for example yum install ./fooTAB - anything that looks like a filesystem path triggers filename-only completion, otherwise we do both filenames and repos. That's atleast understandable but there seems to be a big slowdown when doing rpmlint tab completion as well. Not sure why. rpmlint foo tab is much slower with bash-completion installed. The same thing applies to rpmlint. Anything that looks like a file path gets treated as a file path and is quick; otherwise we need to look up both files and rpmdb, and even though it has been getting better, the latter unfortunately isn't that quick. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usrmove? - about the future
On 2012-02-16 05:34, Stephen John Smoogen wrote: 2) The bash-completions add-on. Which does all kinds of wonderful things which when they work is really nice.. it will autocomplete hostnames if you type ssh ftab, it will autocomplete depending on the command you typed the most obvious items... etc etc. It also can really really slow you down at times or cause issues with just normal bash completion. A bad autocomplete can cause you to sit 3-4 minutes as DNS or other things time out. People tend to bring this up every now and then but fail to be specific exactly what happened so it's quite difficult for anyone to fix things. Nevertheless, a lot of things have improved in bash-completion recently and semi-recently (especially the dynamically loaded version in F-17+), including suppression of unnecessary network accesses by default. But some network accesses intentionally remain, for example remote filename completion for scp and rsync. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usrmove? - about the future
On 02/18/2012 02:27 PM, Ville Skyttä wrote: People tend to bring this up every now and then but fail to be specific exactly what happened so it's quite difficult for anyone to fix things. I just installed it for sometime and found that yum install footab looks up the online repositories instead of completing the filename in my local path. I would prefer local completion first. Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usrmove? - about the future
On 2012-02-18 18:27, Rahul Sundaram wrote: On 02/18/2012 02:27 PM, Ville Skyttä wrote: People tend to bring this up every now and then but fail to be specific exactly what happened so it's quite difficult for anyone to fix things. I just installed it for sometime and found that yum install footab looks up the online repositories instead of completing the filename in my local path. I would prefer local completion first. You can get the completion to work according to that preference with for example yum install ./fooTAB - anything that looks like a filesystem path triggers filename-only completion, otherwise we do both filenames and repos. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usrmove? - about the future
On 02/18/2012 11:05 PM, Ville Skyttä wrote: You can get the completion to work according to that preference with for example yum install ./fooTAB - anything that looks like a filesystem path triggers filename-only completion, otherwise we do both filenames and repos. That's atleast understandable but there seems to be a big slowdown when doing rpmlint tab completion as well. Not sure why. rpmlint foo tab is much slower with bash-completion installed. Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usrmove? - about the future
On Thu, 2012-02-16 at 17:49 +, Jóhann B. Guðmundsson wrote: On 02/16/2012 05:33 PM, Jóhann B. Guðmundsson wrote: complete -r if memory serves me correct then again I'm getting old and fragile... set disable-completion on into /etc/inputrc or ~/.inputr to disable it across logout/reboots This disables normal non-programmable tab-completion for me. Also, if you want the (other) default settings, you need to $include /etc/inputrc on the first line of ~/.inputrc. It would really help if we shipped documentation for this file :-). Nils -- Nils Philippsen Those who would give up Essential Liberty to purchase Red Hat a little Temporary Safety, deserve neither Liberty n...@redhat.com nor Safety. -- Benjamin Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usrmove? - about the future
On Fri, Feb 17, 2012 at 13:54, Nils Philippsen n...@redhat.com wrote: This disables normal non-programmable tab-completion for me. Also, if you want the (other) default settings, you need to $include /etc/inputrc on the first line of ~/.inputrc. It would really help if we shipped documentation for this file :-). man readline. man bash has a bit of information from a bash perspective too. -- There are 10 kinds of people in the world: Those who understand binary and those who don't... -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usrmove? - about the future
Matthew Garrett wrote: On Wed, Feb 15, 2012 at 07:23:24PM -0500, Steve Clark wrote: On 02/15/2012 05:19 PM, mike cloaked wrote: I use bash completion all the time every single day - I guess I have become a corner case! No you haven't. All the developers I have worked with since the early nineties use it all the time every day. We would be lost without it. You may have been working with them since the earliy nineties, but the feature was only introduced in 2.04 in 2000. Programmable completion is fairly modern compared to the rest of bash... That was one of the reasons I switched to zsh. It had far superior completion back then. Bash has closed the gap, since. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usrmove and path ordering
Reindl Harald wrote: Am 15.02.2012 13:43, schrieb Martin Langhoff: On Feb 15, 2012 6:16 AM, Reindl Harald h.rei...@thelounge.net mailto:h.rei...@thelounge.net wrote: there is no single reason for a feature like /usrmove which in fact nobody NEEDS at all and definitly not now to press it into the next release with pressure You are wrong. The /usr move has a very clear impact in being able to snapshot your OS install partition. Add btrfs, yum hooks and the already-implemented stateless configuration and you have a really major feature: a fully upgrade/test/rollback setup for Fedora. only one out of a million installations have /usr seperated from / and the default is NOT do this - so no there is no impact on any normal setup Prior to F17, I've always put /usr on a partition separate from /. $ df -hT / /usr Filesystem Type Size Used Avail Use% Mounted on /dev/sda4 ext4 11G 7.3G 3.2G 70% / /dev/sda6 ext4 10G 7.3G 2.3G 77% /usr I know I'm special ;-), but *that* special? I doubt it. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usrmove? - about the future
- Original Message - From: Steve Clark scl...@netwolves.com To: Development discussions related to Fedora devel@lists.fedoraproject.org Sent: Thursday, February 16, 2012 6:47:03 AM Subject: Re: /usrmove? - about the future On 02/15/2012 10:34 PM, Matthew Garrett wrote: On Wed, Feb 15, 2012 at 07:23:24PM -0500, Steve Clark wrote: On 02/15/2012 05:19 PM, mike cloaked wrote: I use bash completion all the time every single day - I guess I have become a corner case! No you haven't. All the developers I have worked with since the early nineties use it all the time every day. We would be lost without it. You may have been working with them since the earliy nineties, but the feature was only introduced in 2.04 in 2000. Programmable completion is fairly modern compared to the rest of bash... bash 1.14 used readline which had completions. Circa 1994. Thank you very much. And yet still, has nothing at all to do with the bash-completion package being discussed here. Steve -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usrmove? - about the future
On 02/16/2012 08:12 AM, Steve Gordon wrote: - Original Message - From: Steve Clarkscl...@netwolves.com To: Development discussions related to Fedoradevel@lists.fedoraproject.org Sent: Thursday, February 16, 2012 6:47:03 AM Subject: Re: /usrmove? - about the future On 02/15/2012 10:34 PM, Matthew Garrett wrote: On Wed, Feb 15, 2012 at 07:23:24PM -0500, Steve Clark wrote: On 02/15/2012 05:19 PM, mike cloaked wrote: I use bash completion all the time every single day - I guess I have become a corner case! No you haven't. All the developers I have worked with since the early nineties use it all the time every day. We would be lost without it. You may have been working with them since the earliy nineties, but the feature was only introduced in 2.04 in 2000. Programmable completion is fairly modern compared to the rest of bash... bash 1.14 used readline which had completions. Circa 1994. Thank you very much. And yet still, has nothing at all to do with the bash-completion package being discussed here. Steve Oops - sorry for my confusion. -- Stephen Clark *NetWolves* Director of Technology Phone: 813-579-3200 Fax: 813-882-0209 Email: steve.cl...@netwolves.com http://www.netwolves.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usrmove and path ordering
On Thu, 2012-02-16 at 13:22 +0100, Jim Meyering wrote: Reindl Harald wrote: Am 15.02.2012 13:43, schrieb Martin Langhoff: On Feb 15, 2012 6:16 AM, Reindl Harald h.rei...@thelounge.net mailto:h.rei...@thelounge.net wrote: there is no single reason for a feature like /usrmove which in fact nobody NEEDS at all and definitly not now to press it into the next release with pressure You are wrong. The /usr move has a very clear impact in being able to snapshot your OS install partition. Add btrfs, yum hooks and the already-implemented stateless configuration and you have a really major feature: a fully upgrade/test/rollback setup for Fedora. only one out of a million installations have /usr seperated from / and the default is NOT do this - so no there is no impact on any normal setup Prior to F17, I've always put /usr on a partition separate from /. $ df -hT / /usr Filesystem Type Size Used Avail Use% Mounted on /dev/sda4 ext4 11G 7.3G 3.2G 70% / /dev/sda6 ext4 10G 7.3G 2.3G 77% /usr I know I'm special ;-), but *that* special? I doubt it. I guess it is time to change habits, what's the point of a separate /usr these days ? Simo. -- Simo Sorce * Red Hat, Inc * New York -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usrmove? - about the future
On Thu, Feb 16, 2012 at 03:34, Stephen John Smoogen smo...@gmail.com wrote: A bad autocomplete can cause you to sit 3-4 minutes as DNS or other things time out. Ctrl+C will cancel the command and the completion with it. It's not ideal if you are typing a long command but it certainly avoids waiting 3-4 minutes... -- There are 10 kinds of people in the world: Those who understand binary and those who don't... -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usrmove and path ordering
Simo Sorce wrote: On Thu, 2012-02-16 at 13:22 +0100, Jim Meyering wrote: ... Prior to F17, I've always put /usr on a partition separate from /. $ df -hT / /usr Filesystem Type Size Used Avail Use% Mounted on /dev/sda4 ext4 11G 7.3G 3.2G 70% / /dev/sda6 ext4 10G 7.3G 2.3G 77% /usr I know I'm special ;-), but *that* special? I doubt it. I guess it is time to change habits, what's the point of a separate /usr these days ? I like to keep / very small, separate and mostly read-only, so that when something goes wrong with the disk it's less likely to affect the root partition, so I'm all for the implicit writable/read-only segregation this implies. /usrmove is a clear win. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usrmove and path ordering
SS == Simo Sorce s...@redhat.com writes: SS I guess it is time to change habits, what's the point of a separate SS /usr these days ? I also always configured a separate /usr until I decided to obey systemd's complaints about it being broken (though of course I never had any issue at all with it). For me it was simply keeping / small and being able to back it up easily without backing up all of the stuff in /usr. - J -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usrmove? - about the future
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/16/2012 09:59 AM, John5342 wrote: On Thu, Feb 16, 2012 at 03:34, Stephen John Smoogen smo...@gmail.com wrote: A bad autocomplete can cause you to sit 3-4 minutes as DNS or other things time out. Ctrl+C will cancel the command and the completion with it. It's not ideal if you are typing a long command but it certainly avoids waiting 3-4 minutes... Is there a way to disable this. Basically i don't want any bash completion to use the network. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk89PDQACgkQrlYvE4MpobM4wACgkpow10x1tiC+xBarTgXvcmAn IxcAnjEd8WgkDTZfeBTsC1RFAnTbb9dM =lEP8 -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usrmove? - about the future
On 02/16/2012 05:26 PM, Daniel J Walsh wrote: Is there a way to disable this. Basically i don't want any bash completion to use the network. complete -r if memory serves me correct then again I'm getting old and fragile... JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usrmove? - about the future
On 02/16/2012 05:33 PM, Jóhann B. Guðmundsson wrote: complete -r if memory serves me correct then again I'm getting old and fragile... set disable-completion on into /etc/inputrc or ~/.inputr to disable it across logout/reboots JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usrmove and path ordering
On Wed, Feb 15, 2012 at 1:26 AM, Kevin Kofler kevin.kof...@chello.at wrote: Lennart Poettering wrote: Because dropping these dirs from the search paths is merely an optimization, not a requirement. You call it an optimization, I call it fixing a pessimization (performance regression). And as the original message in the thread points out, the regression actually affects more than just performance, it also causes genuine bugs (with automatic prefix detection in applications). So? Should we drop all features that aren't bug free after feature freeze? You complain as if we are going to release GA tomorrow. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usrmove? - about the future
Am 14.02.2012 19:16, schrieb Jóhann B. Guðmundsson: On 02/14/2012 10:23 AM, Alfredo Ferrari wrote: Do the systemd maintainers ever read bug reports BTW? Why do you think otherwise? Not only read them but fix them as well. To give you some stats There are currently 96 Open bugs against systemd and 536 that have been closed at the time of this writing... In F15 which should be the most buggied release since it was the initial release into the distribution only has 11 bugs will systemctl restart ever has working autocompletion for RUNNING services? it is a littl ebit odd the it does show STOPPED services because restart makes ususally more sense for running ones... signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usrmove? - about the future
On 02/15/2012 10:47 AM, Reindl Harald wrote:
Am 14.02.2012 19:16, schrieb Jóhann B. Guðmundsson:
On 02/14/2012 10:23 AM, Alfredo Ferrari wrote:
Do the systemd maintainers ever read bug reports BTW?
Why do you think otherwise?
Not only read them but fix them as well.
To give you some stats
There are currently 96 Open bugs against systemd and 536 that have been closed
at the time of this writing...
In F15 which should be the most buggied release since it was the initial
release into the distribution only has 11
bugs
will systemctl restart ever has working autocompletion for RUNNING services?
it is a littl ebit odd the it does show STOPPED services because
restart makes ususally more sense for running ones...
You could edit /etc/bash_completion.d/systemd-bash-completion.sh to do
this for you.
Replace the $( __get_all_units | grep ...)) with $( __get_active_units ) )
.
.
.
elif __contains_word $verb ${VERBS[RESTARTABLE_UNITS]}; then
comps=$( __filter_units_by_property CanStart yes \
$( __get_all_units | grep -Ev
'\.(device|snapshot|socket|timer)$' ))
.
.
.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usrmove? - about the future
Am 15.02.2012 10:53, schrieb Brendan Jones: On 02/15/2012 10:47 AM, Reindl Harald wrote: Am 14.02.2012 19:16, schrieb Jóhann B. Guðmundsson: On 02/14/2012 10:23 AM, Alfredo Ferrari wrote: Do the systemd maintainers ever read bug reports BTW? Why do you think otherwise? Not only read them but fix them as well. To give you some stats There are currently 96 Open bugs against systemd and 536 that have been closed at the time of this writing... In F15 which should be the most buggied release since it was the initial release into the distribution only has 11 bugs will systemctl restart ever has working autocompletion for RUNNING services? it is a littl ebit odd the it does show STOPPED services because restart makes ususally more sense for running ones... You could edit /etc/bash_completion.d/systemd-bash-completion.sh to do this for you. i could setup also linux from scratch that is not the point the question is: do systemd-developers never use TAB and type all their stuff completly like on a windows box that they do not recognize this at the first place? this is a category of bug where i always expect that no report is needed since every developer using his software is expected to take notice of this signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usrmove and path ordering
On 02/15/2012 10:37 AM, drago01 wrote: On Wed, Feb 15, 2012 at 1:26 AM, Kevin Koflerkevin.kof...@chello.at wrote: Lennart Poettering wrote: Because dropping these dirs from the search paths is merely an optimization, not a requirement. You call it an optimization, I call it fixing a pessimization (performance regression). And as the original message in the thread points out, the regression actually affects more than just performance, it also causes genuine bugs (with automatic prefix detection in applications). So? Should we drop all features that aren't bug free after feature freeze? Yes. We've forked f17 and you guys are still chasing elementary bugs. What do you expect Fedora users to think of this? It communicates a nice impression of the quality of your works. Better stop this non-sense now! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usrmove and path ordering
On Wed, Feb 15, 2012 at 11:18 AM, Ralf Corsepius rc040...@freenet.de wrote: On 02/15/2012 10:37 AM, drago01 wrote: On Wed, Feb 15, 2012 at 1:26 AM, Kevin Koflerkevin.kof...@chello.at wrote: Lennart Poettering wrote: Because dropping these dirs from the search paths is merely an optimization, not a requirement. You call it an optimization, I call it fixing a pessimization (performance regression). And as the original message in the thread points out, the regression actually affects more than just performance, it also causes genuine bugs (with automatic prefix detection in applications). So? Should we drop all features that aren't bug free after feature freeze? Yes. We've forked f17 and you guys are still chasing elementary bugs. elementary bugs ? You got to be either kidding or trolling. What do you expect Fedora users to think of this? We are at pre alpha / alpha ... users should not have to care about that right now. It communicates a nice impression of the quality of your works. I am not involved in this so it is not my works ... Better stop this non-sense now! The only nonsense I see here is people ranting for the sake of ranting. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usrmove and path ordering
Am 15.02.2012 11:25, schrieb drago01: So? Should we drop all features that aren't bug free after feature freeze? Yes. We've forked f17 and you guys are still chasing elementary bugs. elementary bugs ? You got to be either kidding or trolling. What do you expect Fedora users to think of this? We are at pre alpha / alpha ... users should not have to care about that right now. It communicates a nice impression of the quality of your works. I am not involved in this so it is not my works ... Better stop this non-sense now! The only nonsense I see here is people ranting for the sake of ranting. people are ranting because the experience how buggy are features in the GA-releases if they are in such a not conesquently thought state at alpha the last releases it was always fact that they was not ready until GA and if they can't be fixed then common bugs are listed in the release notes the problem is here that first the work/change/feature is started as happend often in the past and in the middle of the work more and more people coming with things nobody cared in tghe planning phase what let many of us feel like there is nothing planned, there were people starting and forcing without any thoughts and the hope that all will get sorted until GA signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usrmove? - about the future
On 02/15/2012 11:55 AM, Reindl Harald wrote: Am 15.02.2012 10:53, schrieb Brendan Jones: On 02/15/2012 10:47 AM, Reindl Harald wrote: Am 14.02.2012 19:16, schrieb Jóhann B. Guðmundsson: On 02/14/2012 10:23 AM, Alfredo Ferrari wrote: Do the systemd maintainers ever read bug reports BTW? Why do you think otherwise? Not only read them but fix them as well. To give you some stats There are currently 96 Open bugs against systemd and 536 that have been closed at the time of this writing... In F15 which should be the most buggied release since it was the initial release into the distribution only has 11 bugs will systemctl restart ever has working autocompletion for RUNNING services? it is a littl ebit odd the it does show STOPPED services because restart makes ususally more sense for running ones... You could edit /etc/bash_completion.d/systemd-bash-completion.sh to do this for you. i could setup also linux from scratch that is not the point the question is: do systemd-developers never use TAB and type all their stuff completly like on a windows box that they do not recognize this at the first place? this is a category of bug where i always expect that no report is needed since every developer using his software is expected to take notice of this As you obviously haven't lost your ability to type, and your keyboard appears to have all the necessary non-tab keys still in place: file a bug on it if it bothers you so much. It might be a shocking revelation to you but not everybody uses or relies their world on bash autocompletion. - Panu - -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usrmove and path ordering
Am 15.02.2012 11:20 schrieb Ralf Corsepius rc040...@freenet.de: Yes. We've forked f17 and you guys are still chasing elementary bugs. What do you expect Fedora users to think of this? It communicates a nice impression of the quality of your works. Better stop this non-sense now rofl... nothing else is broken and my PATH is non-optimal, stop the usrmove, because I don't want it. this is so ridicoulus... -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usrmove and path ordering
On 15/02/12 10:18, Ralf Corsepius wrote: So? Should we drop all features that aren't bug free after feature freeze? Yes. We've forked f17 and you guys are still chasing elementary bugs. What do you expect Fedora users to think of this? It communicates a nice impression of the quality of your works. Better stop this non-sense now! I'm a user, don't have a problem. -- Regards FRank -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usrmove and path ordering
Am 15.02.2012 12:05, schrieb Harald Hoyer: Am 15.02.2012 11:20 schrieb Ralf Corsepius rc040...@freenet.de mailto:rc040...@freenet.de: Yes. We've forked f17 and you guys are still chasing elementary bugs. What do you expect Fedora users to think of this? It communicates a nice impression of the quality of your works. Better stop this non-sense now rofl... nothing else is broken and my PATH is non-optimal, stop the usrmove, because I don't want it. the nothing else we will see later fact is that the feauture is included and now people are coming did we think about this and this and this... there is no single reason for a feature like /usrmove which in fact nobody NEEDS at all and definitly not now to press it into the next release with pressure this feels like you guys has no other things to do and sitting there hmm let us search for solutions press into a release and let us search for constructed problems the solution may solve to have any valid reason to do it now signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usrmove? - about the future
On Mon, 2012-02-13 at 09:28 -0800, Adam Williamson wrote: On Mon, 2012-02-13 at 14:47 +0100, Nils Philippsen wrote: On Fri, 2012-02-10 at 11:08 -0800, Adam Williamson wrote: Let me put it this way, then: Fedora is released on a six month cycle, which is far faster than is usually considered desirable for server usage. It has a 13 month lifetime, which is far shorter than is usually considered desirable for server usage. Its key values and goals are assuredly not compatible with typical server usage - e.g. First - We believe in the power of innovation and showing off new work in our releases. Since we release twice a year, you never have to wait long to see the latest and greatest software, while there are other Linux products derived from Fedora you can use for long-term stability. We always keep Fedora moving forward so that you can see the future first. There are numerous practical policies derived from these values which are clearly not optimal for server usage, such as the short freeze times, relatively low barrier of entry to disruptive features, and QA focus on installation and basic desktop use (we do virtually no QA on any kind of server usage). Finally, there are *several* Linux distributions available which have none of the above 'shortcomings' (so far as server usage is concerned). I'd say the same 'shortcomings' also hurt the end user case. The non-technical people I deal with loathe how we often introduce new features and break stuff (or just their way of doing things) in the process, even in updates -- I've stopped counting the Oh, updates. I wonder what you guys have broken now.-style comments by my wife. To me, Fedora is much better suited to be run on servers than by end users -- admins usually can help themselves in these situations. Don't take this as being against the slew of features Fedora introduces: personally I'm much in favor of systemd, the /usr move, pulseaudio and all that stuff -- there's no point in just treading water and being on the forefront of things is where Fedora is supposed to be. But let's not kid ourselves into thinking that with a life-cycle of only 13 months and the amount of change we introduce in each new release (especially on the desktop) we're somehow catering to end users who don't have a technically skilled spouse, relative or friend in the background to help if things don't work as expected. That also, at least arguably, isn't Fedora's aim (if it was, we'd be doing a terrible job of it, I agree). To cite the Board again: https://fedoraproject.org/wiki/User_base Voluntary Linux consumer Computer-friendly Likely collaborator General productivity user Those four - especially 'computer-friendly' and 'likely collaborator' - don't scream 'end user' to me. My personal take has always been that Fedora is not the friendly desktop operating system of today, but a *prototype* of the friendly desktop operating system of tomorrow. A constantly moving prototype - so it never sits still and becomes the friendly desktop operating system of today. :) Of course :-). In the light of that however, I don't really understand the Fedora is not for servers arguments brought forth every so often... Fedora is not well-suited if what you want is longevity, full stop. Disregarding that point, Fedora on a server is quite hassle-free :-). Nils -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- Nils Philippsen Those who would give up Essential Liberty to purchase Red Hat a little Temporary Safety, deserve neither Liberty n...@redhat.com nor Safety. -- Benjamin Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usrmove and path ordering
On Wed, Feb 15, 2012 at 12:16:07PM +0100, Reindl Harald wrote: there is no single reason for a feature like /usrmove which in fact nobody NEEDS at all and definitly not now to press it into the next release with pressure Well, I need usrmove, because I have a strong need for clean system. Here, your point is invalid. Harald, you are generating copius amounts of stop-energy. You really should participate in Fedora process as it designed - during feature proposals, discussions, implementation. Right now you are ranting post factum. The amount of time you waste on this mail list is huge, and it is a sad waste. It would be better spent on filling bugs on real issues. Because bugs, you know, get fixed. I even remember one bug that you have filled about some deamon not shipping a systemd unit. I saw this bug, I've created and attached unit file, it got shipped by maintainer. Case closed. This is the best way of participation. Your baseless, repetitive rants finally made me blacklist you. It's very sad for me, as I believe in open participation and meritocracy. Good bye, -- Tomasz TorczTo co nierealne -- tutaj jest normalne. xmpp: zdzich...@chrome.pl Ziomale na życie mają tu patenty specjalne. pgpsRQfuuDJox.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usrmove? - about the future
On 02/15/2012 05:49 AM, Panu Matilainen wrote: On 02/15/2012 11:55 AM, Reindl Harald wrote: Am 15.02.2012 10:53, schrieb Brendan Jones: On 02/15/2012 10:47 AM, Reindl Harald wrote: Am 14.02.2012 19:16, schrieb Jóhann B. Guðmundsson: On 02/14/2012 10:23 AM, Alfredo Ferrari wrote: Do the systemd maintainers ever read bug reports BTW? Why do you think otherwise? Not only read them but fix them as well. To give you some stats There are currently 96 Open bugs against systemd and 536 that have been closed at the time of this writing... In F15 which should be the most buggied release since it was the initial release into the distribution only has 11 bugs will systemctl restart ever has working autocompletion for RUNNING services? it is a littl ebit odd the it does show STOPPED services because restart makes ususally more sense for running ones... You could edit /etc/bash_completion.d/systemd-bash-completion.sh to do this for you. i could setup also linux from scratch that is not the point the question is: do systemd-developers never use TAB and type all their stuff completly like on a windows box that they do not recognize this at the first place? this is a category of bug where i always expect that no report is needed since every developer using his software is expected to take notice of this As you obviously haven't lost your ability to type, and your keyboard appears to have all the necessary non-tab keys still in place: file a bug on it if it bothers you so much. It might be a shocking revelation to you but not everybody uses or relies their world on bash autocompletion. - Panu - What world are you living in? -- Stephen Clark *NetWolves* Director of Technology Phone: 813-579-3200 Fax: 813-882-0209 Email: steve.cl...@netwolves.com http://www.netwolves.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usrmove and path ordering
Am 15.02.2012 12:24, schrieb Tomasz Torcz: On Wed, Feb 15, 2012 at 12:16:07PM +0100, Reindl Harald wrote: there is no single reason for a feature like /usrmove which in fact nobody NEEDS at all and definitly not now to press it into the next release with pressure Well, I need usrmove, because I have a strong need for clean system. Here, your point is invalid. you mean all existing linux-installations are unclean? you need a clean system but accept that half of the distribution is a mix of systemd/sysv/lsb - you would get a clean system if the work of one feature would be COMPLETLY done before the next is started, but seems that most people have no intention nor the make nor any idea what is a clean system signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usrmove and path ordering
On Feb 15, 2012 6:16 AM, Reindl Harald h.rei...@thelounge.net wrote:
there is no single reason for a feature like /usrmove which
in fact nobody NEEDS at all and definitly not now to press
it into the next release with pressure
You are wrong. The /usr move has a very clear impact in being able to
snapshot your OS install partition. Add btrfs, yum hooks and the
already-implemented stateless configuration and you have a really major
feature: a fully upgrade/test/rollback setup for Fedora.
For OLPC for example, this could be a major win, hence my interest. I
definitely want it for my laptop. I'm sure many running rawhide will want
it :-) -- upgrade/test/file bugs if it breaks/rollback if it's real bad.
cheers,
m
{ Martin Langhoff - one laptop per child }
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usrmove and path ordering
Am 15.02.2012 13:43, schrieb Martin Langhoff: On Feb 15, 2012 6:16 AM, Reindl Harald h.rei...@thelounge.net mailto:h.rei...@thelounge.net wrote: there is no single reason for a feature like /usrmove which in fact nobody NEEDS at all and definitly not now to press it into the next release with pressure You are wrong. The /usr move has a very clear impact in being able to snapshot your OS install partition. Add btrfs, yum hooks and the already-implemented stateless configuration and you have a really major feature: a fully upgrade/test/rollback setup for Fedora. only one out of a million installations have /usr seperated from / and the default is NOT do this - so no there is no impact on any normal setup signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usrmove and path ordering
On Wed, Feb 15, 2012 at 1:43 PM, Martin Langhoff martin.langh...@gmail.com wrote: You are wrong. The /usr move has a very clear impact in being able to snapshot your OS install partition. Add btrfs, yum hooks and the already-implemented stateless configuration and you have a really major feature: a fully upgrade/test/rollback setup for Fedora. I haven't seen this work and I don't think such snaphots can be relied upon: /boot, /etc and /var are affected by installs as well (especially in the cases where you would want to roll back); I don't think anybody wants exactly the separation provided by the crude /usr vs. rest that is provided by the /usr move. And snapshots that can not be relied upon may be even worse than no snapshots if they motivate users to skip creating proper backups. Mirek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usrmove and path ordering
Am 15.02.2012 14:25, schrieb Miloslav Trmač: On Wed, Feb 15, 2012 at 1:43 PM, Martin Langhoff martin.langh...@gmail.com wrote: You are wrong. The /usr move has a very clear impact in being able to snapshot your OS install partition. Add btrfs, yum hooks and the already-implemented stateless configuration and you have a really major feature: a fully upgrade/test/rollback setup for Fedora. I haven't seen this work and I don't think such snaphots can be relied upon: /boot, /etc and /var are affected by installs as well (especially in the cases where you would want to roll back); I don't think anybody wants exactly the separation provided by the crude /usr vs. rest that is provided by the /usr move. this is a additional reason why the /usrmove is completly useless because it suggests users they are save using any FS-snapshot have many fun after a big upgrade to revert the snapshot if you really have /usr on a seperated FS and your /etc and /var/lib/rpm will stay in the state after the upgrade and your FS is bombed back so for users having a default setup there is no difference because / as /etc and /usr is the same FS and for ones have seperated /usr it does not bring any benefit in real life with other words: the whole work which is done here is useless and low brained with constrcuted arguments not working in the real life and they were only coonstructed to push this feature because some developers are bored and fear this maybe happen also to users if they do not change permanently things which are working fine yes i know, now i get a reply about politness - but face the truth! signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usrmove? - about the future
On 02/15/2012 05:06 PM, Steve Clark wrote: On 02/15/2012 05:49 AM, Panu Matilainen wrote: It might be a shocking revelation to you but not everybody uses or relies their world on bash autocompletion. - Panu - What world are you living in? bash-completion is not a default package. Obviously only a small percentage of users are going to use it. This isn't something you need to debate about. If it was used by the majority, it would be there by default already. Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usrmove? - about the future
Am 15.02.2012 17:59, schrieb Rahul Sundaram: On 02/15/2012 05:06 PM, Steve Clark wrote: On 02/15/2012 05:49 AM, Panu Matilainen wrote: It might be a shocking revelation to you but not everybody uses or relies their world on bash autocompletion. - Panu - What world are you living in? bash-completion is not a default package. Obviously only a small percentage of users are going to use it. This isn't something you need to debate about. If it was used by the majority, it would be there by default already. it is used by all professional users using mostly a terminal it should not installed as deafult because desktop users do not need it at all, but this does not change the fact that systemd developers which i still call professional users should be more sensitive here - especially since the old /sbin/service had completion like a charme! signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usrmove and path ordering
On Wed, Feb 15, 2012 at 8:30 AM, Reindl Harald h.rei...@thelounge.net wrote: Am 15.02.2012 14:25, schrieb Miloslav Trmač: I haven't seen this work and I don't think such snaphots can be relied upon: /boot, /etc and /var are affected by installs as well Miroslav -- you haven't seen this work because the tasks are not all yet in. But the stateless feature handles a lot of it already. this is a additional reason why the /usrmove is completly Harald, it is one step in a process. I am very happy and thankful that Fedora is working in this direction. Now, it's time for me to step aside from this thread. m -- martin.langh...@gmail.com mar...@laptop.org -- Software Architect - OLPC - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usrmove? - about the future
Once upon a time, Rahul Sundaram methe...@gmail.com said: bash-completion is not a default package. Wrong since F16 - it is default in the Base group in comps. -- Chris Adams cmad...@hiwaay.net 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
Re: /usrmove? - about the future
On 02/15/2012 10:40 PM, Reindl Harald wrote: it is used by all professional users using mostly a terminal it should not installed as deafult because desktop users do not need it at all, but this does not change the fact that systemd developers which i still call professional users should be more sensitive here - especially since the old /sbin/service had completion like a charme! Have you filed a bug report yet? Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usrmove? - about the future
On 02/15/2012 10:48 PM, Chris Adams wrote: Once upon a time, Rahul Sundaram methe...@gmail.com said: bash-completion is not a default package. Wrong since F16 - it is default in the Base group in comps. Ah. didn't notice that. I haven't done a fresh installation since Fedora 11 or so. Regardless of that, the point remains that it is easier to file a bug report when you find a bug rather than assume the developers have noticed the problem already. I routinely remove bash-completion or disable it in the past because of slowdown in some cases and I suspect I am not the only one. Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usrmove? - about the future
On Wed, Feb 15, 2012 at 11:19:18PM +0530, Rahul Sundaram wrote: On 02/15/2012 10:48 PM, Chris Adams wrote: Once upon a time, Rahul Sundaram methe...@gmail.com said: bash-completion is not a default package. Wrong since F16 - it is default in the Base group in comps. Ah. didn't notice that. I haven't done a fresh installation since Fedora 11 or so. Regardless of that, the point remains that it is easier to file a bug report when you find a bug rather than assume the developers have noticed the problem already. I routinely remove bash-completion or disable it in the past because of slowdown in some cases and I suspect I am not the only one. And people use different shells (zsh seems to be popular), so they won't nottice bugs in something bash-specific. -- Tomasz Torcz 72-| 80-| xmpp: zdzich...@chrome.pl 72-| 80-| -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usrmove? - about the future
Am 15.02.2012 18:40, schrieb Rahul Sundaram: On 02/15/2012 10:40 PM, Reindl Harald wrote: it is used by all professional users using mostly a terminal it should not installed as deafult because desktop users do not need it at all, but this does not change the fact that systemd developers which i still call professional users should be more sensitive here - especially since the old /sbin/service had completion like a charme! Have you filed a bug report yet? i SURELY have made a notice in one of many bug-reports belonging to systemd last year signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usrmove? - about the future
Am 15.02.2012 18:53, schrieb Tomasz Torcz: On Wed, Feb 15, 2012 at 11:19:18PM +0530, Rahul Sundaram wrote: On 02/15/2012 10:48 PM, Chris Adams wrote: Once upon a time, Rahul Sundaram methe...@gmail.com said: bash-completion is not a default package. Wrong since F16 - it is default in the Base group in comps. Ah. didn't notice that. I haven't done a fresh installation since Fedora 11 or so. Regardless of that, the point remains that it is easier to file a bug report when you find a bug rather than assume the developers have noticed the problem already. I routinely remove bash-completion or disable it in the past because of slowdown in some cases and I suspect I am not the only one. And people use different shells (zsh seems to be popular), so they won't nottice bugs in something bash-specific. does not matter because bash is the default shell and transitions have to be targeted for defaults and any developer of core-components has to use system defaults for his testings signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usrmove? - about the future
On 02/15/2012 07:10 PM, Reindl Harald wrote: Am 15.02.2012 17:59, schrieb Rahul Sundaram: On 02/15/2012 05:06 PM, Steve Clark wrote: On 02/15/2012 05:49 AM, Panu Matilainen wrote: It might be a shocking revelation to you but not everybody uses or relies their world on bash autocompletion. - Panu - What world are you living in? bash-completion is not a default package. Obviously only a small percentage of users are going to use it. This isn't something you need to debate about. If it was used by the majority, it would be there by default already. it is used by all professional users using mostly a terminal No it is not. Many perhaps, but many does not equal all. it should not installed as deafult because desktop users do not need it at all, but this does not change the fact that systemd developers which i still call professional users should be more sensitive here - especially since the old /sbin/service had completion like a charme! For all this talk about professionals, the professional thing to do is to go file the bug already. Crying out OMG they broke my tab! Those bastards! in a mailing list thread about /usrmove is not particularly likely to get noticed by the people who might actually care and fix the damn apparently rather trivial thing. - Panu - -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usrmove? - about the future
On 02/16/2012 12:13 AM, Reindl Harald wrote: i SURELY have made a notice in one of many bug-reports belonging to systemd last year I don't recall seeing it and I am cc'ed in all systemd bug reports and also, individual bugs require individual bug reports. Not merely a note in another bug report which makes it harder to keep track of bugs and mark them as fixed. Do file seperate bug reports from now on. Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usrmove? - about the future
On Wed, Feb 15, 2012 at 07:45:41PM +0100, Reindl Harald wrote: does not matter because bash is the default shell and transitions have to be targeted for defaults and any developer of core-components has to use system defaults for his testings I'm sorry, it's clear at this point that you have expectations of our workflow that aren't terribly well aligned with those of the developers. I'd suggest that you'll spend much less of your time angry if you migrate to a distribution that's more receptive to your preferences. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usrmove? - about the future
On Wed, 2012-02-15 at 18:10 +0100, Reindl Harald wrote: Am 15.02.2012 17:59, schrieb Rahul Sundaram: On 02/15/2012 05:06 PM, Steve Clark wrote: On 02/15/2012 05:49 AM, Panu Matilainen wrote: It might be a shocking revelation to you but not everybody uses or relies their world on bash autocompletion. - Panu - What world are you living in? bash-completion is not a default package. Obviously only a small percentage of users are going to use it. This isn't something you need to debate about. If it was used by the majority, it would be there by default already. it is used by all professional users using mostly a terminal yeah...I'm getting paid for this, so I guess I'm a professional user, and I use terminals an awful lot, but I don't use bash-completion. Every time I ever tried it I found, like Rahul, that it makes things slow and tends to get in my way more than it ever does help me. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usrmove? - about the future
On Wed, Feb 15, 2012 at 8:30 PM, Adam Williamson awill...@redhat.com wrote: On Wed, 2012-02-15 at 18:10 +0100, Reindl Harald wrote: Am 15.02.2012 17:59, schrieb Rahul Sundaram: On 02/15/2012 05:06 PM, Steve Clark wrote: On 02/15/2012 05:49 AM, Panu Matilainen wrote: It might be a shocking revelation to you but not everybody uses or relies their world on bash autocompletion. - Panu - What world are you living in? bash-completion is not a default package. Obviously only a small percentage of users are going to use it. This isn't something you need to debate about. If it was used by the majority, it would be there by default already. it is used by all professional users using mostly a terminal yeah...I'm getting paid for this, so I guess I'm a professional user, and I use terminals an awful lot, but I don't use bash-completion. Every time I ever tried it I found, like Rahul, that it makes things slow and tends to get in my way more than it ever does help me. I use bash completion all the time every single day - I guess I have become a corner case! -- mike c -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usrmove and path ordering
Martin Langhoff wrote: Miroslav -- you haven't seen this work because the tasks are not all yet in. But the stateless feature handles a lot of it already. If you revert /usr to a snapshot without touching the rpmdb (in /var/lib/rpm), your system will be in a very inconsistent state. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usrmove? - about the future
On 02/15/2012 05:19 PM, mike cloaked wrote: On Wed, Feb 15, 2012 at 8:30 PM, Adam Williamsonawill...@redhat.com wrote: On Wed, 2012-02-15 at 18:10 +0100, Reindl Harald wrote: Am 15.02.2012 17:59, schrieb Rahul Sundaram: On 02/15/2012 05:06 PM, Steve Clark wrote: On 02/15/2012 05:49 AM, Panu Matilainen wrote: It might be a shocking revelation to you but not everybody uses or relies their world on bash autocompletion. - Panu - What world are you living in? bash-completion is not a default package. Obviously only a small percentage of users are going to use it. This isn't something you need to debate about. If it was used by the majority, it would be there by default already. it is used by all professional users using mostly a terminal yeah...I'm getting paid for this, so I guess I'm a professional user, and I use terminals an awful lot, but I don't use bash-completion. Every time I ever tried it I found, like Rahul, that it makes things slow and tends to get in my way more than it ever does help me. I use bash completion all the time every single day - I guess I have become a corner case! No you haven't. All the developers I have worked with since the early nineties use it all the time every day. We would be lost without it. -- Stephen Clark *NetWolves* Director of Technology Phone: 813-579-3200 Fax: 813-882-0209 Email: steve.cl...@netwolves.com http://www.netwolves.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usrmove? - about the future
On 15/02/12 01:30 PM, Adam Williamson wrote: On Wed, 2012-02-15 at 18:10 +0100, Reindl Harald wrote: Am 15.02.2012 17:59, schrieb Rahul Sundaram: On 02/15/2012 05:06 PM, Steve Clark wrote: On 02/15/2012 05:49 AM, Panu Matilainen wrote: It might be a shocking revelation to you but not everybody uses or relies their world on bash autocompletion. - Panu - What world are you living in? bash-completion is not a default package. Obviously only a small percentage of users are going to use it. This isn't something you need to debate about. If it was used by the majority, it would be there by default already. it is used by all professional users using mostly a terminal yeah...I'm getting paid for this, so I guess I'm a professional user, and I use terminals an awful lot, but I don't use bash-completion. Every time I ever tried it I found, like Rahul, that it makes things slow and tends to get in my way more than it ever does help me. Right. And thanks to this thread I just learned what broke bash completion for me after fresh install of F16: 'rpm -e bash-completion' fixed bash for me :-) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usrmove? - about the future
On 02/16/2012 07:46 AM, Dariusz J. Garbowski wrote: Right. And thanks to this thread I just learned what broke bash completion for me after fresh install of F16: 'rpm -e bash-completion' fixed bash for me :-) As a quick note; you should probably use yum remove instead of rpm -e because yumdb will be consistent if you stick to yum and that allows rollback etc. Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usrmove? - about the future
On 15 February 2012 17:23, Steve Clark scl...@netwolves.com wrote: On 02/15/2012 05:19 PM, mike cloaked wrote: On Wed, Feb 15, 2012 at 8:30 PM, Adam Williamson awill...@redhat.com wrote: On Wed, 2012-02-15 at 18:10 +0100, Reindl Harald wrote: Am 15.02.2012 17:59, schrieb Rahul Sundaram: On 02/15/2012 05:06 PM, Steve Clark wrote: On 02/15/2012 05:49 AM, Panu Matilainen wrote: It might be a shocking revelation to you but not everybody uses or relies their world on bash autocompletion. - Panu - What world are you living in? bash-completion is not a default package. Obviously only a small percentage of users are going to use it. This isn't something you need to debate about. If it was used by the majority, it would be there by default already. it is used by all professional users using mostly a terminal yeah...I'm getting paid for this, so I guess I'm a professional user, and I use terminals an awful lot, but I don't use bash-completion. Every time I ever tried it I found, like Rahul, that it makes things slow and tends to get in my way more than it ever does help me. I use bash completion all the time every single day - I guess I have become a corner case! No you haven't. All the developers I have worked with since the early nineties use it all the time every day. We would be lost without it. Before getting too far down this rabbit hole... realize there are two bash-completions 1) The built in one. I type ls chtab and bash goes to look at things and either completes or gives me a list of possible completions. 2) The bash-completions add-on. Which does all kinds of wonderful things which when they work is really nice.. it will autocomplete hostnames if you type ssh ftab, it will autocomplete depending on the command you typed the most obvious items... etc etc. It also can really really slow you down at times or cause issues with just normal bash completion. A bad autocomplete can cause you to sit 3-4 minutes as DNS or other things time out. The people talking in this conversation are talking about 2. The type you are talking about is 1. Completely different. -- Stephen J Smoogen. The core skill of innovators is error recovery, not failure avoidance. Randy Nelson, President of Pixar University. Years ago my mother used to say to me,... Elwood, you must be oh so smart or oh so pleasant. Well, for years I was smart. I recommend pleasant. You may quote me. —James Stewart as Elwood P. Dowd -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usrmove? - about the future
On Wed, Feb 15, 2012 at 07:23:24PM -0500, Steve Clark wrote: On 02/15/2012 05:19 PM, mike cloaked wrote: I use bash completion all the time every single day - I guess I have become a corner case! No you haven't. All the developers I have worked with since the early nineties use it all the time every day. We would be lost without it. You may have been working with them since the earliy nineties, but the feature was only introduced in 2.04 in 2000. Programmable completion is fairly modern compared to the rest of bash... -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usrmove? - about the future
https://bugzilla.redhat.com/show_bug.cgi?id=753339 ... and reboot is still not working on Fedora 16 on several machines... do the systemd maintainers ever read bug reports BTW? ++ | Alfredo Ferrari || Tel.: +41.22.767.6119 | | C.E.R.N.|| Fax.: +41.22.767.7555 | | European Laboratory for Particle Physics||| | AB Division / ATB Group || e-mail: | | 1211 Geneva 23 || alfredo.ferr...@cern.ch| | Switzerland || alfredo.ferr...@mi.infn.it | ++ On Fri, 10 Feb 2012, Jef Spaleta wrote: On Fri, Feb 10, 2012 at 8:21 AM, Reindl Harald h.rei...@thelounge.net wrote: F15 was the first Linux i saw where reboot did not work until you typed kill 1 while praying! Can you point me to a bug report from you or anyone else that has been confirmed by at least one other person? I personally didn't experience that with the F15 systems I had. But maybe I got lucked and dodged a bullet. -jef -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usrmove? - about the future
https://bugzilla.redhat.com/show_bug.cgi?id=753339 ... with clean install and on Fedora 16, two duifferent machines ++ | Alfredo Ferrari || Tel.: +41.22.767.6119 | | C.E.R.N.|| Fax.: +41.22.767.7555 | | European Laboratory for Particle Physics||| | AB Division / ATB Group || e-mail: | | 1211 Geneva 23 || alfredo.ferr...@cern.ch| | Switzerland || alfredo.ferr...@mi.infn.it | ++ On Fri, 10 Feb 2012, Bruno Wolff III wrote: On Fri, Feb 10, 2012 at 08:28:28 -0900, Jef Spaleta jspal...@gmail.com wrote: I personally didn't experience that with the F15 systems I had. But maybe I got lucked and dodged a bullet. It seems pretty common that updating systemd causes problems with the next shutdown. I don't know why and it is a pain to reproduce since it doesn't happen again on the next reboot. I don't know if there are tickets corresponding to these issues, but I have seen other people make similar observations. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usrmove? - about the future
Alfredo Ferrari wrote: https://bugzilla.redhat.com/show_bug.cgi?id=753339 ... and reboot is still not working on Fedora 16 on several machines... It's not obvious whether systemd is to blame for this bug. do the systemd maintainers ever read bug reports BTW? Of course. You have comments from one of the maintainers in the very bugreport you linked to. Michal, a systemd co-maintainer -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usrmove and path ordering
On Tue, 2012-02-14 at 17:08 +0100, Michel Alexandre Salim wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dear developers, Now that the /usrmove changes have landed in the F-17 branch, should the ordering of directories in PATH be changed? /usr/bin should appear before /bin and /usr/sbin before /sbin. Right now $(which a-binary) would report that all /usr/... binaries are located in /bin and /sbin instead; while it is mostly just cosmetic, some programs (e.g. pure-gen) use the heuristic of computing their default installation prefix based on the location of another binary, and get confused if that prefix is empty. Is this a reasonable change? I'll file a bug report if that's the case. /bin and /sbin paths were already removed in latest setup package - as you no longer need them... so no need for bugzilla and report... Ondrej Vasik -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usrmove and path ordering
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/14/2012 05:11 PM, Ondrej Vasik wrote: On Tue, 2012-02-14 at 17:08 +0100, Michel Alexandre Salim wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dear developers, Now that the /usrmove changes have landed in the F-17 branch, should the ordering of directories in PATH be changed? /usr/bin should appear before /bin and /usr/sbin before /sbin. Right now $(which a-binary) would report that all /usr/... binaries are located in /bin and /sbin instead; while it is mostly just cosmetic, some programs (e.g. pure-gen) use the heuristic of computing their default installation prefix based on the location of another binary, and get confused if that prefix is empty. Is this a reasonable change? I'll file a bug report if that's the case. /bin and /sbin paths were already removed in latest setup package - as you no longer need them... so no need for bugzilla and report... Ah, great. They are still used in Koji (even for Rawhide) but it's probably just a matter of time then. - -- Michel Alexandre Salim Fedora Project Contributor: http://fedoraproject.org/ Email: sali...@fedoraproject.org | GPG key ID: A36A937A Jabber: hir...@jabber.ccc.de | IRC: hir...@irc.freenode.net () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJPOoufAAoJEEr1VKujapN60mgH/j5MaVuaqZKdqYuwyGA2/7tX pl+KOJDBWdaAhFjz9MFNYlN5CtEVt+pGIEf0MuuDe9VKgNk+GNisThTI+9qtYVXz MEjdl0FdGuPCIhPHnLGJwRqW4KPsByn2BVAzMJP+jCwSjYqwS3qN7/3LQPkZILaq 0MaApVxOUZYT2E1XpJqy7ad5fPj5TAorU9hn5+VJC+pgg8R0XNO5rU77CXMHI+MK vwf7weHu3OOhlnqiXB4FH7DrtDla6hemlww78AuCE3tRCQ0QjaYjeoqpATBni9O6 qT6MvfTgR1LmvzD+j6rhpM+ndmjDhJ1AtFOku0zwFSDddtDft2AtMzOIxm2DxJ4= =14en -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usrmove and path ordering
On Tue, 2012-02-14 at 17:11 +0100, Ondrej Vasik wrote: On Tue, 2012-02-14 at 17:08 +0100, Michel Alexandre Salim wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dear developers, Now that the /usrmove changes have landed in the F-17 branch, should the ordering of directories in PATH be changed? /usr/bin should appear before /bin and /usr/sbin before /sbin. Right now $(which a-binary) would report that all /usr/... binaries are located in /bin and /sbin instead; while it is mostly just cosmetic, some programs (e.g. pure-gen) use the heuristic of computing their default installation prefix based on the location of another binary, and get confused if that prefix is empty. Is this a reasonable change? I'll file a bug report if that's the case. /bin and /sbin paths were already removed in latest setup package - as you no longer need them... so no need for bugzilla and report... I'm not sure, but I think bash has hardcoded PATH for /bin and /usr/bin as well. -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usrmove and path ordering
On Tue, 2012-02-14 at 17:33 +0100, Tomas Mraz wrote: On Tue, 2012-02-14 at 17:11 +0100, Ondrej Vasik wrote: On Tue, 2012-02-14 at 17:08 +0100, Michel Alexandre Salim wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dear developers, Now that the /usrmove changes have landed in the F-17 branch, should the ordering of directories in PATH be changed? /usr/bin should appear before /bin and /usr/sbin before /sbin. Right now $(which a-binary) would report that all /usr/... binaries are located in /bin and /sbin instead; while it is mostly just cosmetic, some programs (e.g. pure-gen) use the heuristic of computing their default installation prefix based on the location of another binary, and get confused if that prefix is empty. Is this a reasonable change? I'll file a bug report if that's the case. /bin and /sbin paths were already removed in latest setup package - as you no longer need them... so no need for bugzilla and report... I'm not sure, but I think bash has hardcoded PATH for /bin and /usr/bin as well. Also, has the default linker path (in glibc, I guess?) been adjusted? -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usrmove and path ordering
- Original Message - On Tue, 2012-02-14 at 17:11 +0100, Ondrej Vasik wrote: On Tue, 2012-02-14 at 17:08 +0100, Michel Alexandre Salim wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dear developers, Now that the /usrmove changes have landed in the F-17 branch, should the ordering of directories in PATH be changed? /usr/bin should appear before /bin and /usr/sbin before /sbin. Right now $(which a-binary) would report that all /usr/... binaries are located in /bin and /sbin instead; while it is mostly just cosmetic, some programs (e.g. pure-gen) use the heuristic of computing their default installation prefix based on the location of another binary, and get confused if that prefix is empty. Is this a reasonable change? I'll file a bug report if that's the case. /bin and /sbin paths were already removed in latest setup package - as you no longer need them... so no need for bugzilla and report... I'm not sure, but I think bash has hardcoded PATH for /bin and /usr/bin as well. You are right, setup update fixed only /sbin locations... /bin has to be done on glibc and shells side. Sorry for confusion... Greetings, Ondrej Vasik -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usrmove? - about the future
On 02/14/2012 10:23 AM, Alfredo Ferrari wrote: Do the systemd maintainers ever read bug reports BTW? Why do you think otherwise? Not only read them but fix them as well. To give you some stats There are currently 96 Open bugs against systemd and 536 that have been closed at the time of this writing... In F15 which should be the most buggied release since it was the initial release into the distribution only has 11 bugs 1 one actual bug but a very low priority one ( Proper solution to that fixm needs to be thought out before implementing it ) The rest are DOC and RFE's and 2 misfiled once ( nis and mdadm which affects all release and has been fixed in F17/rawhide ). I think those stats speak for themselves and the people doing the work behind it. JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usrmove and path ordering
Ondrej Vasik wrote: You are right, setup update fixed only /sbin locations... /bin has to be done on glibc and shells side. Sorry for confusion... WHY was UsrMove allowed to be merged in such broken and incomplete state? Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usrmove and path ordering
On Tue, 14.02.12 23:08, Kevin Kofler (kevin.kof...@chello.at) wrote: Ondrej Vasik wrote: You are right, setup update fixed only /sbin locations... /bin has to be done on glibc and shells side. Sorry for confusion... WHY was UsrMove allowed to be merged in such broken and incomplete state? Because dropping these dirs from the search paths is merely an optimization, not a requirement. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usrmove and path ordering
Lennart Poettering wrote: Because dropping these dirs from the search paths is merely an optimization, not a requirement. You call it an optimization, I call it fixing a pessimization (performance regression). And as the original message in the thread points out, the regression actually affects more than just performance, it also causes genuine bugs (with automatic prefix detection in applications). Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usrmove? - about the future
On 02/10/2012 07:12 PM, Jon Ciesla wrote: Given all that, it seems only logical to conclude that Fedora really _isn't_ primarily intended for use as a production server. Bingo, which is why it's important for people like me who do it to realize what they're getting into and take some responsibility for that choice, like with any other technological choice. If you aren't will to either take downtime for Anaconda or preupgrade, or do lots of fresh installs, or mess with yum upgrades, use RHEL/CO/SL/Etc. Not for the feint of heart, and I sure as heck don't do it at work. :) For what it's worth, I *do* use it at work and on the whole I have very little trouble. Yes, upgrading can be a PITA, but it's usually just a few hours. I don't mind. Andrew. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usrmove?
On Fri, Feb 10, 2012 at 08:09:41PM +0100, Lennart Poettering wrote:
Hmm, you are aware that you reach the biggest compat by just symlinking
/bin to /usr/bin?
Yeah, that's the end goal, but we need rpm to support replacing
directories with symlinks first. Thus we don't rush the change.
Cheers,
Michael.
--
Michael Schroeder m...@suse.de
SUSE LINUX Products GmbH, GF Jeff Hawn, HRB 16746 AG Nuernberg
main(_){while(_=~getchar())putchar(~_-1/(~(_|32)/13*2-11)*13);}
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usrmove?
On Mon, Feb 13, 2012 at 12:13 PM, Michael Schroeder m...@suse.de wrote: On Fri, Feb 10, 2012 at 08:09:41PM +0100, Lennart Poettering wrote: Hmm, you are aware that you reach the biggest compat by just symlinking /bin to /usr/bin? Yeah, that's the end goal, but we need rpm to support replacing directories with symlinks first. Thus we don't rush the change. That's unlikely to ever happen though. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usrmove?
On Mon, Feb 13, 2012 at 12:25:08PM +0100, drago01 wrote:
On Mon, Feb 13, 2012 at 12:13 PM, Michael Schroeder m...@suse.de wrote:
On Fri, Feb 10, 2012 at 08:09:41PM +0100, Lennart Poettering wrote:
Hmm, you are aware that you reach the biggest compat by just symlinking
/bin to /usr/bin?
Yeah, that's the end goal, but we need rpm to support replacing
directories with symlinks first. Thus we don't rush the change.
That's unlikely to ever happen though.
Uh, why do you think so? I hope that you're aware that some rpm
development also happens outside of Redhat/Fedora.
Cheers,
Michael.
--
Michael Schroeder m...@suse.de
SUSE LINUX Products GmbH, GF Jeff Hawn, HRB 16746 AG Nuernberg
main(_){while(_=~getchar())putchar(~_-1/(~(_|32)/13*2-11)*13);}
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usrmove?
On Mon, Feb 13, 2012 at 12:31 PM, Michael Schroeder m...@suse.de wrote: On Mon, Feb 13, 2012 at 12:25:08PM +0100, drago01 wrote: On Mon, Feb 13, 2012 at 12:13 PM, Michael Schroeder m...@suse.de wrote: On Fri, Feb 10, 2012 at 08:09:41PM +0100, Lennart Poettering wrote: Hmm, you are aware that you reach the biggest compat by just symlinking /bin to /usr/bin? Yeah, that's the end goal, but we need rpm to support replacing directories with symlinks first. Thus we don't rush the change. That's unlikely to ever happen though. Uh, why do you think so? I hope that you're aware that some rpm development also happens outside of Redhat/Fedora. A recent comment from Panu that I can't find right now. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usrmove? - about the future
On Fri, 2012-02-10 at 11:08 -0800, Adam Williamson wrote: Let me put it this way, then: Fedora is released on a six month cycle, which is far faster than is usually considered desirable for server usage. It has a 13 month lifetime, which is far shorter than is usually considered desirable for server usage. Its key values and goals are assuredly not compatible with typical server usage - e.g. First - We believe in the power of innovation and showing off new work in our releases. Since we release twice a year, you never have to wait long to see the latest and greatest software, while there are other Linux products derived from Fedora you can use for long-term stability. We always keep Fedora moving forward so that you can see the future first. There are numerous practical policies derived from these values which are clearly not optimal for server usage, such as the short freeze times, relatively low barrier of entry to disruptive features, and QA focus on installation and basic desktop use (we do virtually no QA on any kind of server usage). Finally, there are *several* Linux distributions available which have none of the above 'shortcomings' (so far as server usage is concerned). I'd say the same 'shortcomings' also hurt the end user case. The non-technical people I deal with loathe how we often introduce new features and break stuff (or just their way of doing things) in the process, even in updates -- I've stopped counting the Oh, updates. I wonder what you guys have broken now.-style comments by my wife. To me, Fedora is much better suited to be run on servers than by end users -- admins usually can help themselves in these situations. Don't take this as being against the slew of features Fedora introduces: personally I'm much in favor of systemd, the /usr move, pulseaudio and all that stuff -- there's no point in just treading water and being on the forefront of things is where Fedora is supposed to be. But let's not kid ourselves into thinking that with a life-cycle of only 13 months and the amount of change we introduce in each new release (especially on the desktop) we're somehow catering to end users who don't have a technically skilled spouse, relative or friend in the background to help if things don't work as expected. Nils -- Nils Philippsen Those who would give up Essential Liberty to purchase Red Hat a little Temporary Safety, deserve neither Liberty n...@redhat.com nor Safety. -- Benjamin Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usrmove? - about the future
On Mon, 2012-02-13 at 14:47 +0100, Nils Philippsen wrote: On Fri, 2012-02-10 at 11:08 -0800, Adam Williamson wrote: Let me put it this way, then: Fedora is released on a six month cycle, which is far faster than is usually considered desirable for server usage. It has a 13 month lifetime, which is far shorter than is usually considered desirable for server usage. Its key values and goals are assuredly not compatible with typical server usage - e.g. First - We believe in the power of innovation and showing off new work in our releases. Since we release twice a year, you never have to wait long to see the latest and greatest software, while there are other Linux products derived from Fedora you can use for long-term stability. We always keep Fedora moving forward so that you can see the future first. There are numerous practical policies derived from these values which are clearly not optimal for server usage, such as the short freeze times, relatively low barrier of entry to disruptive features, and QA focus on installation and basic desktop use (we do virtually no QA on any kind of server usage). Finally, there are *several* Linux distributions available which have none of the above 'shortcomings' (so far as server usage is concerned). I'd say the same 'shortcomings' also hurt the end user case. The non-technical people I deal with loathe how we often introduce new features and break stuff (or just their way of doing things) in the process, even in updates -- I've stopped counting the Oh, updates. I wonder what you guys have broken now.-style comments by my wife. To me, Fedora is much better suited to be run on servers than by end users -- admins usually can help themselves in these situations. Don't take this as being against the slew of features Fedora introduces: personally I'm much in favor of systemd, the /usr move, pulseaudio and all that stuff -- there's no point in just treading water and being on the forefront of things is where Fedora is supposed to be. But let's not kid ourselves into thinking that with a life-cycle of only 13 months and the amount of change we introduce in each new release (especially on the desktop) we're somehow catering to end users who don't have a technically skilled spouse, relative or friend in the background to help if things don't work as expected. That also, at least arguably, isn't Fedora's aim (if it was, we'd be doing a terrible job of it, I agree). To cite the Board again: https://fedoraproject.org/wiki/User_base Voluntary Linux consumer Computer-friendly Likely collaborator General productivity user Those four - especially 'computer-friendly' and 'likely collaborator' - don't scream 'end user' to me. My personal take has always been that Fedora is not the friendly desktop operating system of today, but a *prototype* of the friendly desktop operating system of tomorrow. A constantly moving prototype - so it never sits still and becomes the friendly desktop operating system of today. :) -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usrmove?
Am 11.02.2012 00:12 schrieb Chuck Anderson c...@wpi.edu: On Fri, Feb 10, 2012 at 08:39:47AM -0800, Toshio Kuratomi wrote: nod So one idea would be that a specific FESCo member needs to step up to be the collaboration guide (Must think of a better name for that :-) for a feature. They would be in charge of the feature, watch it as it evolves. Pick apart all the points where it requires coordination with other groups. And make sure that those groups were informed that the feature was in progress. Feature Shepherd That is a great idea! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usrmove?
On Fri, Feb 10, 2012 at 5:45 AM, Ralf Corsepius rc040...@freenet.de wrote: [...] To draw an arbitrary example from recent past: Ask yourself - What was the shape of systemd in F15/F16? Has the situation been fixed in F17? Just for the record I didn't have *any* systemd related problem in F15 and neither have one in F16. So from my point of view there is nothing to get fixed. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usrmove?
On 02/10/2012 04:45 AM, Ralf Corsepius wrote: On 02/09/2012 11:06 PM, Jared K. Smith wrote: On Thu, Feb 9, 2012 at 11:57 AM, Ralf Corsepiusrc040...@freenet.de wrote: IMO, Fedora has obvious problems with its - work-flow (Too immature SW migrates/sneaks through from Alpha/Beta to Final) If you feel this is the case, feel free to help improve the work-flow, or at a minimum help write better Alpha/Beta/Final release criteria to help us catch things you consider immature. Let me put it this way: I am having difficulties in recalling any Fedora release which worked for me out of the box ... In earlier releases there for example were pulseaudio and SELinux, in current releases it's primarily systemd, in F17 I am sure it will be the usemore stuff, which will cause trouble. You can go further back if you like.. NetworkManager,X, KMS,Radeon,Nouveau,etc... But yes there is a pattern not only on a bit level but also policy wize ( we have had the tendency up to this point to implement policy's without having any tools or process to measure the outcome of that policy ). - management, whom seems to be driven by a must have at any price, no point of return ever policy. I'm not sure who you're referring to as management here Everybody involved to drawing strategic and tactical decisions related to the Fedora distribution. My point is, I feel there is a lack of monitoring, reporting, and a sense of responsibility of the different bodies involved and of people who are able to draw unpleasant decisions. To draw an arbitrary example from recent past: Ask yourself - What was the shape of systemd in F15/F16? Has the situation been fixed in F17? You need to be a bit more specific on what situation regarding systemd you are referring to? Bugs are actively being fixed and worked on for example I don't believe we have any bug open against systemd in F15 which is not an RFE or DOC ( somewhere between 10 - 15 bugs in total ). The state of overall migration to systemd is depended on each package maintainer(s) and at current rate that wont be finished until F20+. If you got some ideas how to *motivate* those maintainers to migrate to systemd even if they would just simply package and ship the submitted unit files many of them have received I'm all ears but unfortunately the only way I see that finish in a reasonable time is if FESCO blocks the relevant package from the release. FESCO has avoided thus far to go down that path even thou it already was clear that this was going to be an issue after the F15 release. That said, IMO, on the technical side, Fedora urgently needs a calming down/lean back/settlement phase, say 2 consecutive Fedora releases without revolutionary features being introduced, to revisit re-evaluate, revert/complete old revolutionary features. If we wanted we could release Fedora LTS which Red Hat's could use as bases for their RHEL which also would server as the free alternative RHEL users demand for ( And our infrastructure would actually have faith in the bits we ship and run on top of that ) and have a constant rolling release ( Fedora/Rawhide ) as opposed to be having 2 GA releases and Rawhide... ( or some variant of the above proposal ) In this spirit, I eg. would propose to table usrmove for F17 and to concentrate on systemd integration and anaconda/grub2 improvements, both topics, I perceived as the hall of shame of F16. Better systemd integration of services is not going to happen I can just tell you that here and now unless fesco brings fourth the big hammer or packagers get their act together. The said state of systemd migration only reflects the said state of package maintainership in the distribution... JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usrmove?
Am 10.02.2012 08:36, schrieb Ondrej Vasik: On Fri, 2012-02-10 at 05:45 +0100, Ralf Corsepius wrote: On 02/09/2012 11:06 PM, Jared K. Smith wrote: - management, whom seems to be driven by a must have at any price, no point of return ever policy. I'm not sure who you're referring to as management here Everybody involved to drawing strategic and tactical decisions related to the Fedora distribution. My point is, I feel there is a lack of monitoring, reporting, and a sense of responsibility of the different bodies involved and of people who are able to draw unpleasant decisions. To draw an arbitrary example from recent past: Ask yourself - What was the shape of systemd in F15/F16? Has the situation been fixed in F17? Wrt. F17: usrmove - Independently from the fact that I consider it to be an idotic foolishness, ask yourself if it is a shape to be part of F17? IMO, it's foreseeable it will not be ready, because there are too many unknows attached to it. I now would expect those people having been involved to stand up, show responsibility and revisit their decisions - This obiviously doesn't happen. One additional item to this topic. I'm the Fedora filesystem package maintainer (and because it has it's upstream on the fedorahosted, you can say upstream...) and I was aware of the usrmove feature only from the discussions and feature pages. For quite a long time I waited for an email from Harald - with some please include the changes into upstream git. The only mail I received from him was the mail on 24th of January - saying - do not build the package. Nothing more... Strange - when the first thing for Fedora maintainers should be upstream first and imho violation of Proven It had to happen all at one time in koji. packager rules in some cases . For me it was kind of misusing proven packager - as e.g. in coreutils package he did following change: +%check +# FIXME: check failed!! +# make check (part of http://lists.fedoraproject.org/pipermail/scm-commits/2012-January/725967.html , quite easy to miss when reading the commit mail) without even informing me about that! I don't see disabling testsuite at buildtime as the necessary minimal change. Not saying anything that with the /bin/ provides the spec file looks really like a mess now. The testsuite was failing in rawhide at patch creation time (without any usrmove patches). Works now again. Just turned it on. Given the fact that there is NO ultimate gain from the usrmove feature (ok, I understand all the arguments for the usrmove, but I don't see them that bright at the moment as Harald and fastboot guys - e.g. the compatibility of distro locations is not only in the locations of binaries and we have much more differences in Fedora) That's your personal opinion.. I tend to differ. Please read http://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge again. I really don't know why the REAL ACTIONS on this feature were started that late in F17 release cycle - several months after branching. Because politics took so long. Only 3 weeks after the start of usrmove git commits you now have even F18 git branch and F18 would have been MUCH better for it. In addition, for mock builds of F17+ packages with usrmove support on RHEL-6 systems you now need UNSUPPORTED rpm from Harald pages ( http://people.redhat.com/harald/downloads/rpm/4.8.0-19.el6.0.usrmove.1/ ). and? It will get in RHEL-6.3 ... SUPPORTED! That's a self inflicted wound, binding Fedora development to RHEL-6. I'm sure that reverting the changes at the moment would mean much more confusion and that there is the only option now - finish it. But I hope that FESCO will learn from this feature and will set the deadlines for distro-wide features with higher impact sooner - so there will be enough time to postpone them to Fedora X+1 in the case of immaturity. I think there is a difference between usrmove and e.g. GIMP2.8 feature (no offence to Gimp). Greetings, Ondrej Vasik -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usrmove?
On Fri, Feb 10, 2012 at 01:11:06AM +0100, Kevin Kofler wrote: Yes, I'm arguing that the feature is undesirable by design and should not have been approved, not for Fedora 17, not for Fedora 18, not even for Fedora 31337. It has been approved, other distributions are following. It is very clear you do not want this. But at the same time, it is happening in Fedora and elsewhere (noticed openSUSE, will propose for Mageia 3). I don't think additional emails will change anything about either the feature, or your opinion. In any case, when painting I like the colour white. Though maybe in summer (slightly warmer times), I'll change my mind and choose purple. ;) -- Regards, Olav (lurking:) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usrmove?
On 02/10/2012 10:06 AM, Jóhann B. Guðmundsson wrote: On 02/10/2012 04:45 AM, Ralf Corsepius wrote: In this spirit, I eg. would propose to table usrmove for F17 and to concentrate on systemd integration and anaconda/grub2 improvements, both topics, I perceived as the hall of shame of F16. Better systemd integration of services is not going to happen I can just tell you that here and now Why not? Users are supposed to struggle with the swamp/mess the systemd integration currently is in? Could it be systemd reached its design limitations (== is a failure)? Don't get me wrong, I am honestly asking, because I don't know and because it's in general not uncommmon to see promissing developments to reach 90% of its goals in 10% of the projected time, but to never cover the remaining 10% - Often because for limitations of the design. unless fesco brings fourth the big hammer or packagers get their act together. That's what I meant my responsibility. I am asking the people in charge to draw consequences. This could be to bring out the hammer, it could be to revert, it could be Red Hat to delegate personnel, it could be volunteers to jump in, to bring this unpleasant topic to a proper end. The said state of systemd migration only reflects the said state of package maintainership in the distribution... Well, I do not share this view. IMO, it reflects the attitude of the people behind this development. Ralf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usrmove?
On Fri, Feb 10, 2012 at 5:45 AM, Ralf Corsepius rc040...@freenet.de wrote: Wrt. F17: usrmove - Independently from the fact that I consider it to be an idotic foolishness, ask yourself if it is a shape to be part of F17? IMO, it's foreseeable it will not be ready, because there are too many unknows attached to it. I now would expect those people having been involved to stand up, show responsibility and revisit their decisions - This obiviously doesn't happen. At the moment the feature was again brought up to FESCo two weeks ago, the commits were already in the repository, so reverting the feature would have had a pretty big cost; as much as I oppose the idea of UsrMove, I didn't think reverting it was worth it at that time, and I don't think it is worth it now - the situation is not that hopeless to call for a comparatively extreme measure. (Also, a large part of FESCo clearly wants this, and I don't think reverting features just because elections happened in the mean time is a good idea.) Yes, FESCo * should have recognized early that the scope of the feature was not thought through and that more pieces are needed (contrary to claims back in the end of October that everything is already implemented and works) * probably should have asked for an advance approval from FPC (although, as a general rule, I think advance approval from FPC lengthens the feature cycle too much and should be avoided) * and should have monitored the progress more closely. The feature process is currently being revised, and at least some of these issues have been brought up at https://fedoraproject.org/wiki/Fixing_features . What would be especially useful is to find ways to improve the feature process. Mirek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usrmove?
None of your arguments explain the lack of communication. FESCo give you go even so late in development cycle, because you are well known in Fedora project. We believe that you can make it, because you told us at the start it's tested, it's working. If you said earlier changes in anaconda, rpm and other places are needed, it would be probably postponed into F-18. Such huge change should be discussed with release engineering at the start (in November), not in January. I guess for future features will be a scope with all dependencies a must and a plan of such huge changes will be reviewed by FESCo more closely. Now I really hope that new feature process will be ready for next Fedora. Marcela On 02/10/2012 10:21 AM, Harald Hoyer wrote: Am 10.02.2012 08:36, schrieb Ondrej Vasik: On Fri, 2012-02-10 at 05:45 +0100, Ralf Corsepius wrote: On 02/09/2012 11:06 PM, Jared K. Smith wrote: - management, whom seems to be driven by a must have at any price, no point of return ever policy. I'm not sure who you're referring to as management here Everybody involved to drawing strategic and tactical decisions related to the Fedora distribution. My point is, I feel there is a lack of monitoring, reporting, and a sense of responsibility of the different bodies involved and of people who are able to draw unpleasant decisions. To draw an arbitrary example from recent past: Ask yourself - What was the shape of systemd in F15/F16? Has the situation been fixed in F17? Wrt. F17: usrmove - Independently from the fact that I consider it to be an idotic foolishness, ask yourself if it is a shape to be part of F17? IMO, it's foreseeable it will not be ready, because there are too many unknows attached to it. I now would expect those people having been involved to stand up, show responsibility and revisit their decisions - This obiviously doesn't happen. One additional item to this topic. I'm the Fedora filesystem package maintainer (and because it has it's upstream on the fedorahosted, you can say upstream...) and I was aware of the usrmove feature only from the discussions and feature pages. For quite a long time I waited for an email from Harald - with some please include the changes into upstream git. The only mail I received from him was the mail on 24th of January - saying - do not build the package. Nothing more... Strange - when the first thing for Fedora maintainers should be upstream first and imho violation of Proven It had to happen all at one time in koji. packager rules in some cases . For me it was kind of misusing proven packager - as e.g. in coreutils package he did following change: +%check +# FIXME: check failed!! +# make check (part of http://lists.fedoraproject.org/pipermail/scm-commits/2012-January/725967.html , quite easy to miss when reading the commit mail) without even informing me about that! I don't see disabling testsuite at buildtime as the necessary minimal change. Not saying anything that with the /bin/ provides the spec file looks really like a mess now. The testsuite was failing in rawhide at patch creation time (without any usrmove patches). Works now again. Just turned it on. Given the fact that there is NO ultimate gain from the usrmove feature (ok, I understand all the arguments for the usrmove, but I don't see them that bright at the moment as Harald and fastboot guys - e.g. the compatibility of distro locations is not only in the locations of binaries and we have much more differences in Fedora) That's your personal opinion.. I tend to differ. Please read http://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge again. I really don't know why the REAL ACTIONS on this feature were started that late in F17 release cycle - several months after branching. Because politics took so long. Only 3 weeks after the start of usrmove git commits you now have even F18 git branch and F18 would have been MUCH better for it. In addition, for mock builds of F17+ packages with usrmove support on RHEL-6 systems you now need UNSUPPORTED rpm from Harald pages ( http://people.redhat.com/harald/downloads/rpm/4.8.0-19.el6.0.usrmove.1/ ). and? It will get in RHEL-6.3 ... SUPPORTED! That's a self inflicted wound, binding Fedora development to RHEL-6. I'm sure that reverting the changes at the moment would mean much more confusion and that there is the only option now - finish it. But I hope that FESCO will learn from this feature and will set the deadlines for distro-wide features with higher impact sooner - so there will be enough time to postpone them to Fedora X+1 in the case of immaturity. I think there is a difference between usrmove and e.g. GIMP2.8 feature (no offence to Gimp). Greetings, Ondrej Vasik -- Marcela Mašláňová BaseOS team Brno -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usrmove?
On Fri, Feb 10, 2012 at 11:28:59AM +0100, Olav Vitters wrote:
It has been approved, other distributions are following. It is very
clear you do not want this. But at the same time, it is happening in
Fedora and elsewhere (noticed openSUSE, will propose for Mageia 3).
For openSUSE we're currently doing it in a lightweight fashion,
i.e. no movement of directories (until rpm learns do deal with
those) and no big /bin - /usr/bin symlink.
(We're mostly doing it because to provide some kind of Fedora
compatibility for 3rd parties.)
Cheers,
Michael.
--
Michael Schroeder m...@suse.de
SUSE LINUX Products GmbH, GF Jeff Hawn, HRB 16746 AG Nuernberg
main(_){while(_=~getchar())putchar(~_-1/(~(_|32)/13*2-11)*13);}
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
