Re: [opensuse-factory] distribution meeting - introduction and agenda
On Thu, 17 Aug 2006 14:31:31 +0200, Manfred Hollstein wrote: strings -a /usr/lib64/libapt-pkg-libc6.3-6.so.2.0.0 | fgrep /usr/lib /usr/lib64/apt/methods /usr/lib/apt/scripts As you can see the scripts will be looked up in the architecture independent location /usr/lib/apt (which is correct FWIW), but they are installed under /usr/lib64/apt/scripts unfortunately. Hmm, I don't remember having seen a bugzilla entry for this, otherwise I'm pretty shure I'd have fixed it. Care to file a bug so that I get reminded to fix this? Philipp - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-factory] distribution meeting - introduction and agenda
Am Thursday 17 August 2006 17:47 schrieb Christian Boltz: Hello, Am Donnerstag, 17. August 2006 13:57 schrieb Andreas Jaeger: Christian Boltz [EMAIL PROTECTED] writes: My proposal: KMail, evolution and Thunderbird [1] should come with the local mailbox account /var/spool/mail/username preconfigured so that system mails will be received automatically. Please add this as a feature request on the wiki, OK, it's on http://en.opensuse.org/Feature_Wishlist/Misc now. BTW: Thanks for the (probably not intentional) reminder to propose a better handling for the wishlists. IMHO it's just painful to use the wiki for this... Reasons: - the wiki can't be searched by solution (there are some items marked as solved, but still listed on the page) - if something is finally removed as wontfix from a package wishlist, chances are good that it reappears sooner or later (may happen with done also if it is removed before next stable release) you would have the same with any other tool. It would be better to keep such entries and only add the reason why not to add it. - the package wishlists have a very bad usability - if you want to add a comment or a wish, you have to find your way in the (long) tables right, maybe we should rethink about the format ... Our other solution, which we use inhouse for our buisness products is FATE btw. You may want to play around with it and comment, if you think this is also usable for a community ... http://programm.froscon.de/attachments/41-SuseFeatureManagement_Froscon.pdf#search=%22fate%20suse%22 (we miss a FATE page in www.opensuse.org ... ) My suggestion is to create a openSUSE Wishlist product in bugzilla (with the current wishlists as components), maybe with a special input form to have the fields that are currently in the wishlist always filled. (Yes, I know that there was a package wishlist in bugzilla already in pre-openSUSE times. And I wonder why it was moved to the wiki.) the wiki is way more flexibel here and you can also see all the other package wishes in the same are (so this on might become obsolete). -- Adrian Schroeter SUSE Linux Products GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-factory] distribution meeting - introduction and agenda
On 2006-08-18 09:24:50 +0200, Adrian Schröter wrote: (Yes, I know that there was a package wishlist in bugzilla already in pre-openSUSE times. And I wonder why it was moved to the wiki.) the wiki is way more flexibel here and you can also see all the other package wishes in the same are (so this on might become obsolete). saved searches? darix -- openSUSE - SUSE Linux is my linux openSUSE is good for you www.opensuse.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-factory] distribution meeting - introduction and agenda
LDFLAGS=-Wl,-z relro (see http://people.redhat.com/drepper/nonselsec.pdf) I currently can't see a disadvantage of using this one thus unless someone could actually see one I'd go the same way. Actually we made binutils enable relro by default in Factory yesterday or so. So all binaries get it now, unless explicitly using -z norelro. So far it seems not to have adverse effects. (The -z now option, also referenced above, does have performance impacts and will likely just be added to some specific binaries.) Ciao, Marcus - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-factory] distribution meeting - introduction and agenda
Christian Boltz [EMAIL PROTECTED] writes: Hello, Am Mittwoch, 16. August 2006 16:44 schrieb Andreas Jaeger: Will this work? It depends on some points: - you should give some more background information about the topics - I'll insert some questions regarding this below. I don't know everything and would like to have expert advice ;-) - you should mail some days earlier the next time ;-)) Will try to ;-) The planned topics for tomorrow's meeting are: * D-Bus 0.91 and PolicyKit/resmgr We just switched to D-Bus 0.91 and the question arises whether to continue to use resmgr or switch to PolicyKit. What are the advantages and disadvantages of each? That's what we try to figure out in the meeting. * Move to GNOME 2.16 The packagers have started already with the first packages, we want to discuss the timeframe for the move and the move of GNOME to /usr (from /opt/gnome). Hmm, what's the reason for this? Requests by e.g. lsb. BTW: Will KDE be moved also? With the next major KDE update: Yes, we will. * SuSEconfig removal SuSEconfig is currently run after each package installation by YaST and is a huge bottleneck. Some scripts have already been removed and we have to discuss how to move on. What's the replacement for config files that are _generated_ by SuSEconfig? (as in: including /etc/sysconfig/foo is impossible for the respective application) - You won't be able to do this in rpm postinstall scripts or alike ;-) We have to figure this out for each script. It might be done in the postinstall of the packages that need it - but only there. Not for unrelated stuff. [...] Andreas -- Andreas Jaeger, [EMAIL PROTECTED], http://www.suse.de/~aj/ SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126 pgpoBzqZOHkCY.pgp Description: PGP signature
Re: [opensuse-factory] distribution meeting - introduction and agenda
Em Qui, 2006-08-17 às 12:08 +0200, Andreas Jaeger escreveu:
We have to figure this out for each script. It might be done in the
postinstall of the packages that need it - but only there. Not for
unrelated stuff.
IMHO that should be the desired action, since if you manage packages
using rug or smart none call SuSEconfig at the end of the
operations. So making the package call it on the %post to run only the
needed scripts would be nice.
--
% Mauricio Teixeira (netmask)
% mteixeira{a}webset{d}net Maceio/AL/BR
% http://mteixeira.webset.net http://pmping.sf.net
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-factory] distribution meeting - introduction and agenda
Christian Boltz [EMAIL PROTECTED] writes: My proposal: KMail, evolution and Thunderbird [1] should come with the local mailbox account /var/spool/mail/username preconfigured so that system mails will be received automatically. Please add this as a feature request on the wiki, Andreas -- Andreas Jaeger, [EMAIL PROTECTED], http://www.suse.de/~aj/ SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126 pgp5zUmg8nkHb.pgp Description: PGP signature
Re: [opensuse-factory] distribution meeting - introduction and agenda
Em Qui, 2006-08-17 às 13:04 +0200, Andreas Hanke escreveu:
At least rug runs SuSEconfig after each transaction, and it's _painful_
compared to YaST because other than YaST, it doesn't show what it does,
Well, I've never used rug, so I was not sure about it.
Regarding smart, it's an old request to run SuSEconfig at the end, but
looks like we'll wait for this discussion here to reach a decision so we
would make ours on smart. :)
And sure running the needed scripts on %post would do the trick, but it
would require a lot of documentation so that the packagers would know
if/when/how/why would they need to do that.
--
% Mauricio Teixeira (netmask)
% mteixeira{a}webset{d}net Maceio/AL/BR
% http://mteixeira.webset.net http://pmping.sf.net
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-factory] distribution meeting - introduction and agenda
Hi there, On Thu, 17 Aug 2006, 14:15:58 +0200, Mauricio Teixeira (netmask) wrote: Em Qui, 2006-08-17 às 13:04 +0200, Andreas Hanke escreveu: At least rug runs SuSEconfig after each transaction, and it's _painful_ compared to YaST because other than YaST, it doesn't show what it does, Well, I've never used rug, so I was not sure about it. This would be a design error in the first place, I'd say, as rug knows (should know, at least...) about the _whole_ set of transactions, so it should run SuSEconfig just once, which is at the end of the whole set of transactions. Regarding smart, it's an old request to run SuSEconfig at the end, but looks like we'll wait for this discussion here to reach a decision so we would make ours on smart. :) Dunno if this helps others, but apt-get knows about this since quite some time, and it works amazingly well - on i386 (ie. 32-bit) platforms at least. Unfortunately the x86_64 version has a pathname compiled into its shared library (this is on SL-10.0) libapt-pkg-libc6.3-6.so.2.0.0, which stops running the System::Post:: script(s) (which will call SuSEconfig amongst others): strings -a /usr/lib64/libapt-pkg-libc6.3-6.so.2.0.0 | fgrep /usr/lib /usr/lib64/apt/methods /usr/lib/apt/scripts As you can see the scripts will be looked up in the architecture independent location /usr/lib/apt (which is correct FWIW), but they are installed under /usr/lib64/apt/scripts unfortunately. Creating a corresponding symbolic link cures that problem: ln -snf ../lib64/apt /usr/lib/apt And sure running the needed scripts on %post would do the trick, but it would require a lot of documentation so that the packagers would know if/when/how/why would they need to do that. No, you don't want to run e.g. ldconfig after _each_ RPM you're installing... To be honest, I didn't like SuSEconfig when I first used SUSE Linux (came from Red Hat background...), but I'm not sure what the solution would be that fullfills the same job _and_ with the same efficiency... Cheers. l8er manfred - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-factory] distribution meeting - introduction and agenda
Mauricio Teixeira (netmask) [EMAIL PROTECTED] writes: Em Qui, 2006-08-17 às 13:04 +0200, Andreas Hanke escreveu: At least rug runs SuSEconfig after each transaction, and it's _painful_ compared to YaST because other than YaST, it doesn't show what it does, Well, I've never used rug, so I was not sure about it. Regarding smart, it's an old request to run SuSEconfig at the end, but looks like we'll wait for this discussion here to reach a decision so we would make ours on smart. :) And sure running the needed scripts on %post would do the trick, but it would require a lot of documentation so that the packagers would know if/when/how/why would they need to do that. We already noticed that we have a lot of scripts that are not needed anymore - just historic garbage :-(. Those can be removed. Let's see which scripts we still need and what technical solution is needed. If in the end out of 20 scripts, we keep 2 - and the runtime for these is not anymore 20s on my machine but 1s, then I'm fine ;-) Andreas -- Andreas Jaeger, [EMAIL PROTECTED], http://www.suse.de/~aj/ SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126 pgp9irbW6s4K4.pgp Description: PGP signature
Re: [opensuse-factory] distribution meeting - introduction and agenda
Am Donnerstag, 17. August 2006 14:06 schrieb Andreas Jaeger: FYI, this is RFC for the SuSEconfig discussion written by a colleague. WE do not just want to remove it - we also have to figure out to replace it... Perhaps you could also split from another point of view: Class E: scripts, which have to be run immediately after installing/updating a package, so that the software is usable Class F: scripts, which can be run later, too Class E scripts should remain in SuSEconfig (or any successor). Class F scripts could probably be done by cron, or when CPU is idle for x minutes. When changing scripts from SuSEconfg to cron jobs, please consider that the more things will be done by cron jobs, the more users will be frustrated, if the CPU/disk is going crazy. So doing the main work immediately after installing packages is still the best way, I think. -- Mit freundlichen Grüßen, Marcel Hilzinger Linux New Media AG Süskindstr. 4 D-81929 München Tel: +49 (89) 99 34 11 0 Fax: +49 (89) 99 34 11 99 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-factory] distribution meeting - introduction and agenda
Hi, Manfred Hollstein schrieb: This would be a design error in the first place, I'd say, as rug knows (should know, at least...) about the _whole_ set of transactions, so it should run SuSEconfig just once, which is at the end of the whole set of transactions. That's just a misunderstanding, rug does the same thing as apt and YaST do (I define installing/updating/removing multiple packages at once a single transaction), but it's still too much and too slow. No, you don't want to run e.g. ldconfig after _each_ RPM you're installing... That's exactly what happens currently(!): Every package that contains a shared library runs ldconfig in %post and then, at the end of the transaction, the package manager runs it _again_ (ldconfig is not strictly speaking a SuSEconfig module, but run together with SuSEconfig). It's inefficient and it hides bugs (missing ldconfig calls) in the packages. The same for SuSEconfig.fonts: All font packages (should) run it in %post, but at the end of the transaction, the package manager runs it _again_. Maybe the SuSEconfig modules can be divided into different classes: A class of general-purpose modules where running them after every transaction is more efficient and another class of special-purpose modules where running them after installing the individual packages which need it is more efficient. This split could be based on the classes posted by AJ, but it's not exactly the same: I'm thinking of a split based on how often and when a SuSEconfig module is actually needed, not based on how it works internally. For example, nobody would ever make a SuSEconfig module around mkinitrd although rebuilding the initrd is a task which resembles that of certain SuSEconfig modules. At least some of the existing modules can surely be handled like mkinitrd, i.e., run as needed. Andreas Hanke - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-factory] distribution meeting - introduction and agenda
Hello, Am Donnerstag, 17. August 2006 13:57 schrieb Andreas Jaeger: Christian Boltz [EMAIL PROTECTED] writes: My proposal: KMail, evolution and Thunderbird [1] should come with the local mailbox account /var/spool/mail/username preconfigured so that system mails will be received automatically. Please add this as a feature request on the wiki, OK, it's on http://en.opensuse.org/Feature_Wishlist/Misc now. BTW: Thanks for the (probably not intentional) reminder to propose a better handling for the wishlists. IMHO it's just painful to use the wiki for this... Reasons: - the wiki can't be searched by solution (there are some items marked as solved, but still listed on the page) - if something is finally removed as wontfix from a package wishlist, chances are good that it reappears sooner or later (may happen with done also if it is removed before next stable release) - the package wishlists have a very bad usability - if you want to add a comment or a wish, you have to find your way in the (long) tables My suggestion is to create a openSUSE Wishlist product in bugzilla (with the current wishlists as components), maybe with a special input form to have the fields that are currently in the wishlist always filled. (Yes, I know that there was a package wishlist in bugzilla already in pre-openSUSE times. And I wonder why it was moved to the wiki.) Regards, Christian Boltz -- 1.-4.9.2006: Weinfest in Insheim Pig Slip, Hifi-Delity, AH-Band, Frank Petersen und die Deafen Goblins spielen bei der Landjugend. Mehr Infos: www.Landjugend-Insheim.de - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-factory] distribution meeting - introduction and agenda
Christian Boltz [EMAIL PROTECTED] writes: Hello, Am Donnerstag, 17. August 2006 13:57 schrieb Andreas Jaeger: Christian Boltz [EMAIL PROTECTED] writes: My proposal: KMail, evolution and Thunderbird [1] should come with the local mailbox account /var/spool/mail/username preconfigured so that system mails will be received automatically. Please add this as a feature request on the wiki, OK, it's on http://en.opensuse.org/Feature_Wishlist/Misc now. BTW: Thanks for the (probably not intentional) reminder to propose a better handling for the wishlists. IMHO it's just painful to use the wiki for this... Yes, I know, we're looking into alternatives already, Andreas -- Andreas Jaeger, [EMAIL PROTECTED], http://www.suse.de/~aj/ SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126 pgpArN0yajO6e.pgp Description: PGP signature
[opensuse-factory] distribution meeting - introduction and agenda
We have an internal meeting every few weeks called dist meeting that discusses major technical changes in our distribution. Since it's not possible for most of you to attend it, I'd like to try an experiment and share the agenda before the meeting - and the meeting minutes afterwards with you. I'm asking for your feedback on the agenda and any comments that you have and will bring those comments into the meeting and raise the points you've made. Will this work? The planned topics for tomorrow's meeting are: * D-Bus 0.91 and PolicyKit/resmgr We just switched to D-Bus 0.91 and the question arises whether to continue to use resmgr or switch to PolicyKit. * Move to GNOME 2.16 The packagers have started already with the first packages, we want to discuss the timeframe for the move and the move of GNOME to /usr (from /opt/gnome). * SuSEconfig removal SuSEconfig is currently run after each package installation by YaST and is a huge bottleneck. Some scripts have already been removed and we have to discuss how to move on. * update messages general/conditional (e.g. bind) During update of packages they could notify users about changes via email and/or the SuSEplugger (until 10.0, this is not anymore in 10.1). Most of these are outdated and not really usefull anymore and should be removed. The question is how to handle situations like bind where config files get rewritten and the user should be informed if this fails. * Dropping UP Kernel on i386/x86-64 The proposal by the kernel team is to use only SMP kernels and no UP kernel. It's already this way on Xen - there is no Xen UP kernel. Advantages: One less kernel rpm. On 64bit there will be only two kernel rpms then, kernel-default and kernel-xen; and with some luck if paravirt ops works out as designed we can then later drop kernel-xen too and only ship a single 64bit kernel. 32bit could go down to two. Less QA. Less space on ftp servers. Less build time. Avoids a lot of problems with install kernel being different from final kernel. The i386 UP kernel e.g. doesn't support advanced APIC modes, which broke i386 installation of SLES10 on some systems. We've had quite a lot of bugs in this area over the years. Disadvantages: Will be slightly slower and bigger on UP systems. Most of the performance difference is fixed up by kraxel's LOCK prefix runtime patch. Memory usage will be up a bit on UP systems We would lose a few drivers which are BROKEN_ON_SMP. Usually these are long unmaintained drivers which are broken for other reasons anyways so it's not a big loss. Also we never had them in the SMP kernel and most modern systems run SMP kernels. There might be other bugs caused by this, but Fedora has done this before us and they didn't seem to have regretted it so far. * Linker Options and Optimizations We plan to use the recently developed linker optimizations for the GNU hashstyle and use the readonly relocations: LDFLAGS=-Wl,-O1 -Wl,--hash-style=both (http://lwn.net/Articles/192082/ ) LDFLAGS=-Wl,-z relro (see http://people.redhat.com/drepper/nonselsec.pdf) Andreas -- Andreas Jaeger, [EMAIL PROTECTED], http://www.suse.de/~aj/ SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126 pgp9E2RdkQjvY.pgp Description: PGP signature
Re: [opensuse-factory] distribution meeting - introduction and agenda
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 The packagers have started already with the first packages, we want to discuss the timeframe for the move and the move of GNOME to /usr (from /opt/gnome). I really like this move. I am just concerned that there will not be enough time in the current schedule to complete the entire task. * SuSEconfig removal SuSEconfig is currently run after each package installation by YaST and is a huge bottleneck. Some scripts have already been removed and we have to discuss how to move on. I agree with this. I think the changes needed should be done at the time. I dislike the running of this script all the time. * update messages general/conditional (e.g. bind) During update of packages they could notify users about changes via email and/or the SuSEplugger (until 10.0, this is not anymore in 10.1). Most of these are outdated and not really usefull anymore and should be removed. The question is how to handle situations like bind where config files get rewritten and the user should be informed if this fails. I prefer the email notification. I would like to see the few situations where config files change that an email is sent to root. * Linker Options and Optimizations We plan to use the recently developed linker optimizations for the GNU hashstyle and use the readonly relocations: LDFLAGS=-Wl,-O1 -Wl,--hash-style=both (http://lwn.net/Articles/192082/ ) LDFLAGS=-Wl,-z relro (see http://people.redhat.com/drepper/nonselsec.pdf) I think this is a good move. Also I prefer the dropping of UP kernel. I like having things as close to the same as possible. I think the advantages out way the disadvantages. Thanks, - -- Boyd Gerber [EMAIL PROTECTED] ZENEZ 1042 East Fort Union #135, Midvale Utah 84047 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) Comment: For info see http://quantumlab.net/pine_privacy_guard/ iD8DBQFE40qrVtBjDid73eYRAprDAJ46bLlHfX/JSDvacxSr8KV6OLZ8KwCfSCJG wizHHdAl8jkeu8qddmF//kw= =LAhV -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-factory] distribution meeting - introduction and agenda
On Wed, Aug 16, 2006 at 06:42:44PM +0200, Christian Boltz wrote: Hello, Am Mittwoch, 16. August 2006 16:44 schrieb Andreas Jaeger: Will this work? It depends on some points: - you should give some more background information about the topics - I'll insert some questions regarding this below. Well, if you don't have the background information for a specific topic it might not make much sense to give a comment to that topic, right? And btw. there is not a requirement that you give an answer to all open questions in the universe. ;-) Robert -- Robert Schiele Tel.: +49-621-181-2214 Dipl.-Wirtsch.informatiker mailto:[EMAIL PROTECTED] Quidquid latine dictum sit, altum sonatur. pgpri5rSBoXFf.pgp Description: PGP signature
Re: [opensuse-factory] distribution meeting - introduction and agenda
On Wednesday 16 August 2006 11:44 am, Andreas Jaeger wrote: * update messages general/conditional (e.g. bind) During update of packages they could notify users about changes via email and/or the SuSEplugger (until 10.0, this is not anymore in 10.1). Most of these are outdated and not really usefull anymore and should be removed. The question is how to handle situations like bind where config files get rewritten and the user should be informed if this fails. I believe that sending mail is still the appropriate action. As for the outdated messages, you can set environment variables (eg: SUSE_UPDATE_FROM=900, SUSE_UPDATE_TO=1020) so that %pre and %post scripts can determine whether a message should be sent. -- James Oakley [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
