[opensuse-factory] SPAM: BUG or Feature? Can't replace destructive CD!
When some file on CD installation was damage then the installation STOP anymore. You can not press the Eject button, even point to other media. In Windows (sorry for who hate this OS, this is for example only), when installtion come to damage file then: 1. you can eject the cd and replace with good one 2. you can point to other media such as any drive that contain the good one, a floopy disk, or other cd drive attach to the pc. can you improve opensuse with this feature? the check cd feature is not a good solution and take too longer time to test every cd! __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[opensuse-factory] SPAM: Why evaluating package run every time?
here i describe in these steps below (sorry, hard to explain, easy to show you the steps) : 1. on installation, choose Gnome 2. now you're waiting for suse to Evaluating Package ... hmmm... takes >30 seconds!!! 3. choose Change - Parttition 4. after finishing work with parttion, then when you back to the Installation then Evaluating Package RUN AGAIN. why? i don't make any changing in Package Selection, this only make me wait another > 30 seconds. __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[opensuse-factory] SPAM: Can't install even using text mode and the solution!
PROBLEM 10.2 alpha 2: - Using Asus P4V8X-MX with onboard VGA, Intel Celeron D 2.6 GHz. 1. on first installation screen I press F3 2. then this text appear at left-top screen: --pstx---rstk- : . : : : : err 8 : : ip 5da510.7 : -- 3. then only shows: boot: SOLUTION - 1. this PC (also the seventh PC that I have tested), has W2K Server Standard Edition. 2. so, i try to enter GUI mode, then choose custom partition, and delete entire partition, reboot 3. now installation on mode text is ok! again, this pc when I choose language then press enter: some color change to black! only ofter enter, but on other screen it's fixed. __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[opensuse-factory] SPAM: BUG OR FEATURE? You can by pass SF2!
Using SF2 v3.3 on Suse 10.2 alpha2: - squid on port 8080 with all local client can access internet - SF2: set fw_masq_nets="192.168.0.1" #only this pc can access internet (rule A) - SF2: set to redirect port 80 to 8080 #this is define after fw_masq_nets (rule B) - but... now every client on LAN can access because of the redirecting port Question: - how to make Order in sf2, like: rule B must be apply after A? - how to solve above problem? __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-factory] Packagage Groupings - From Selections in 10.1 to Patterns in 10.2
On Tue, Jul 25, 2006 at 09:10:05PM +0200, Klaus Kaempf wrote: > * houghi <[EMAIL PROTECTED]> [Jul 25. 2006 19:52]: > > > > Would patterns also be able to contain information about installation > > sources? > > No. Repositories offer patterns but not vice versa. Pity. Oh well. We still need things we want to change after 10.2 comes out. :-D -- The whole principle [of censorship] is wrong. It's like demanding that grown men live on skim milk because the baby can't have steak. -- Robert A. Heinlein in "The Man Who Sold the Moon" - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-factory] Packagage Groupings - From Selections in 10.1 to Patterns in 10.2
* houghi <[EMAIL PROTECTED]> [Jul 25. 2006 19:52]: > > Would patterns also be able to contain information about installation > sources? No. Repositories offer patterns but not vice versa. > e.g. if I use a pattern, it will offer me (or add automagicaly) > to add an extra installation source? Well, a pattern could recommend (weak dependency) some 'non-existant' package which will be installed if a repo offering this package is known to the system. Klaus - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-factory] Packagage Groupings - From Selections in 10.1 to Patterns in 10.2
* Pascal Bleser <[EMAIL PROTECTED]> [Jul 25. 2006 19:20]: > > I think we have a slightly different view/understanding of the patterns. > To me, it's not as much high-level packages than rather groups. Patterns is what you make of it ;-) Their basics is dependencies, just like packages have. They support hard (requires) and weak (recommends, suggests) dependencies to patterns or(!) packages. Reverse dependencies (supplements == install me if dependency matches) are also possible. > > I rather see the analogy with RPM Groups or .desktop categories. You can organize patterns like this but to me their real value is in expressing functionalities as building blocks to a complete system. > > btw, just to make sure I got that right, can patterns be organized into > a tree (i.e. do they have a hierarchy) ? > e.g. Development/Database/Server You can express hierachies via dependencies. But the tree you're thinking of is probably better expressed via Keywords and some UI logic. > > > Patterns is about the ability to group packages for better overview > > and handling, mostly at the UI level. Its an abstraction level. > > It's grouping... I wouldn't call that an "abstraction level" though :) > > An "abstraction", to me, would rather be to say "install texteditor" and > you would get kate, emacs, vim or whatever ;) If a pattern 'texteditor' exists, thats exactly what will happen. Ideally, there is one preferred implementation of the functionality 'texteditor'. For a KDE Desktop its probably kate. But this pattern can also list other editors. It could be like 'customers who bought this also bought that' in Amazon. Abstraction to me means mostly getting away from the package flood. If I look for an office suite on the package level, I probably end up with at least 4 OpenOffice packages (OpenOffice_org, OpenOffice_org-Quickstarter, OpenOffice_org-kde and a translation package). On the pattern level, I would only see one entry. > > > However, I do agree that some kind of public 'pattern database' would > > be nice in order to find duplicates and overlaps. > > Totally. > > I really see a risk of ending up with chaos here. > To continue on my analogy with RPM groups and .desktop categories: if we > didn't have a closed set of options to choose from (as defined in the > SUSE Package Conventions), it would be havoc and the end-user KDE/GNOME > menus wouldn't be very deep. > > At the very least, let's keep a pattern database (or rather, just a > list) to try to reuse existing patterns if they match. I agree when looking at keywords as mentioned above. For patterns themselves, a 'creative chaos' might be quite helpful in the beginning. Useful patterns will emerge from this just like distributions emerge from the 'package chaos' which exists in the open source world. [...] > > > It's just that if you see it as an analogy to RPM Groups or .desktop > categories, a package that's in my repository (or packman, or ...) > should be able to merge into a pattern/group/category that's already > present on the SUSE repository (or media), as in the example above. YaST already gives you the 'rpm group' view. Is it helpful ? How can we improve here ? Klaus - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-factory] Packagage Groupings - From Selections in 10.1 to Patterns in 10.2
On Tue, Jul 25, 2006 at 07:19:55PM +0200, Pascal Bleser wrote: > btw, just to make sure I got that right, can patterns be organized into > a tree (i.e. do they have a hierarchy) ? > e.g. Development/Database/Server As patterns can contain other patterns, I would say: yes. > I really see a risk of ending up with chaos here. > To continue on my analogy with RPM groups and .desktop categories: if we > didn't have a closed set of options to choose from (as defined in the > SUSE Package Conventions), it would be havoc and the end-user KDE/GNOME > menus wouldn't be very deep. Yes and no. e.g somebody makes a pattern 'Non SUSE multi-media' that includes all the MPlayer and mad libraries. e.g. when I now select MPlayer, I get all the extra codecs as well. So what the patern would have is e.g.: MPlayer, xmms-mad and k3b-mad (Don't shoot me if this is already included when installing MPlayer) > At the very least, let's keep a pattern database (or rather, just a > list) to try to reuse existing patterns if they match. A database would be extremely helpfull, especially if it were outside of SUSE. That way anybody can add their patterns. Would patterns also be able to contain information about installation sources? e.g. if I use a pattern, it will offer me (or add automagicaly) to add an extra installation source? -- The whole principle [of censorship] is wrong. It's like demanding that grown men live on skim milk because the baby can't have steak. -- Robert A. Heinlein in "The Man Who Sold the Moon" - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-factory] Konsole crashes on Alpha 2
Stephan Kulow kirjoitti: > Am Montag, 24. Juli 2006 20:02 schrieb Arto Viitanen: > >> Stephan Kulow kirjoitti: >> >>> Am Samstag, 22. Juli 2006 15:32 schrieb Arto Viitanen: >>> I did install kdebase3-debuginfo-3.5.3-13.i586.rpm and kdelibs3-debuginfo-3.5.3-15.i586.rpm from http://download.opensuse.org/distribution/SL-OSS-factory/inst-source/sus e/ i586/. Output of the backtrace looks almost the same: >>> I have to asume that there was a rebuild between your alpha2 and that >>> factory snapshot. The RPMs have to fitt 100% >>> >> OK. There was no debuginfo versionc of the RPMs in the CD-images, >> so I assumed the factory files would be fine. Do you know where can >> I get the right versions for Alpha2? >> >> > You need to install factory's kdebase3 together with the debuginfo > I installed the factory version of kdebase3, and now the backtrace looks like System configuration startup check disabled. Using host libthread_db library "/lib/libthread_db.so.1". [Thread debugging using libthread_db enabled] [New Thread -1232128336 (LWP 4474)] [KCrash handler] #6 0xe410 in __kernel_vsyscall () #7 0xb7d957b0 in raise () from /lib/libc.so.6 #8 0xb7d96e83 in abort () from /lib/libc.so.6 #9 0xb7dd04a9 in malloc_printerr () from /lib/libc.so.6 #10 0xb7dd1aa5 in free () from /lib/libc.so.6 #11 0xb6be7101 in operator delete () from /usr/lib/libstdc++.so.6 #12 0xb6be715d in operator delete[] () from /usr/lib/libstdc++.so.6 #13 0xb7263edd in QStringData::deleteSelf () from /usr/lib/qt3/lib/libqt-mt.so.3 #14 0xb7ee260f in TEmulation::onRcvBlock (this=0x81597f0, s=0xbfecdb97 "\033[00;32maurora-seagate.txt\033[00m", ' ' , "\033[00mindex.html\033[00m", ' ' , "\033[00mprint.ps\033[00m\r\n\033[01;34mbin\033[00m", ' ' , "\033[00mindex-long.html\033[00m "..., len=1024) at /usr/lib/qt3/include/qstring.h:848 #15 0xb7ee91b9 in TESession::onRcvBlock (this=0x81596d0, buf=0xbfecdb97 "\033[00;32maurora-seagate.txt\033[00m", ' ' , "\033[00mindex.html\033[00m", ' ' , "\033[00mprint.ps\033[00m\r\n\033[01;34mbin\033[00m", ' ' , "\033[00mindex-long.html\033[00m "..., len=1024) at ./konsole/konsole/session.cpp:746 #16 0xb7ef36fa in TESession::qt_invoke (this=0x81596d0, _id=17, _o=0xbfecda00) at ./konsole/konsole/session.moc:462 #17 0xb6f93d3d in QObject::activate_signal () from /usr/lib/qt3/lib/libqt-mt.so.3 #18 0xb7ecdf38 in TEPty::block_in (this=0x815b4c8, t0=0xbfecdb97 "\033[00;32maurora-seagate.txt\033[00m", ' ' , "\033[00mindex.html\033[00m", ' ' , "\033[00mprint.ps\033[00m\r\n\033[01;34mbin\033[00m", ' ' , "\033[00mindex-long.html\033[00m "..., t1=1024) at ./konsole/konsole/TEPty.moc:143 #19 0xb7ece06b in TEPty::dataReceived (this=0x815b4c8, buf=0xbfecdb97 "\033[00;32maurora-seagate.txt\033[00m", ' ' , "\033[00mindex.html\033[00m", ' ' , "\033[00mprint.ps\033[00m\r\n\033[01;34mbin\033[00m", ' ' , "\033[00mindex-long.html\033[00m "..., len=1024) at ./konsole/konsole/TEPty.cpp:233 #20 0xb7ed5f33 in TEPty::qt_invoke (this=0x815b4c8, _id=8, _o=0xbfecdb0c) at ./konsole/konsole/TEPty.moc:164 #21 0xb6f93d3d in QObject::activate_signal () from /usr/lib/qt3/lib/libqt-mt.so.3 #22 0xb751feee in KProcess::receivedStdout (this=0x815b4c8, t0=0x815b4c8, t1=0xbfecdb97 "\033[00;32maurora-seagate.txt\033[00m", ' ' , "\033[00mindex.html\033[00m", ' ' , "\033[00mprint.ps\033[00m\r\n\033[01;34mbin\033[00m", ' ' , "\033[00mindex-long.html\033[00m "..., t2=1024) at ./kdecore/kprocess.moc:152 #23 0xb751ffc8 in KProcess::childOutput (this=0x815b4c8, fdno=14) at ./kdecore/kprocess.cpp:853 #24 0xb751fff9 in KProcess::slotChildOutput (this=0x815b4c8, fdno=14) at ./kdecore/kprocess.cpp:733 #25 0xb752005a in KProcess::qt_invoke (this=0x815b4c8, _id=2, _o=0xbfece0b4) at ./kdecore/kprocess.moc:201 #26 0xb7ed5eb3 in TEPty::qt_invoke (this=0x815b4c8, _id=2, _o=0xbfece0b4) at ./konsole/konsole/TEPty.moc:169 #27 0xb6f93d3d in QObject::activate_signal () from /usr/lib/qt3/lib/libqt-mt.so.3 #28 0xb6f94882 in QObject::activate_signal () from /usr/lib/qt3/lib/libqt-mt.so.3 #29 0xb72ce6f0 in QSocketNotifier::activated () from /usr/lib/qt3/lib/libqt-mt.so.3 #30 0xb6fb1f50 in QSocketNotifier::event () from /usr/lib/qt3/lib/libqt-mt.so.3 #31 0xb6f34cc7 in QApplication::internalNotify () from /usr/lib/qt3/lib/libqt-mt.so.3 #32 0xb6f35a91 in QApplication::notify () from /usr/lib/qt3/lib/libqt-mt.so.3 #33 0xb75f0a52 in KApplication::notify (this=0xbfece77c, receiver=0x8195458, event=0xbfece368) at ./kdecore/kapplication.cpp:552 #34 0xb6f299a1 in QEventLoop::activateSocketNotifiers () from /usr/lib/qt3/lib/libqt-mt.so.3 #35 0xb6ee4844 in QEventLoop::processEvents () from /usr/lib/qt3/lib/libqt-mt.so.3 #36 0xb6f4bb00 in QEventLoop::enterLoop () from /usr/lib/qt3/lib/libqt-mt.so.3 #37 0xb6f4b996 in QEventLoop::exec () from /usr/lib/qt3/lib/libqt-mt.so.3 #38 0xb6f3487f in QApplicati
Re: [opensuse-factory] YaST2 package upgrade operation (was: Packagage Groupings...)
On Tue, Jul 25, 2006 at 07:04:02PM +0200, Klaus Kaempf wrote: > And this is still true for most enterprise systems. Sysadmins will never > upgrade because a newer version is available but only because of a fixed > bug or a required feature. If it ain't broke, don't fix it. :-) -- The whole principle [of censorship] is wrong. It's like demanding that grown men live on skim milk because the baby can't have steak. -- Robert A. Heinlein in "The Man Who Sold the Moon" - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-factory] Packagage Groupings - From Selections in 10.1 to Patterns in 10.2
Op dinsdag 25 juli 2006 18:49, schreef Klaus Kaempf: > Patterns is about the ability to group packages for better overview > and handling, mostly at the UI level. Its an abstraction level. > > However, I do agree that some kind of public 'pattern database' would > be nice in order to find duplicates and overlaps. Is it perhaps comparable to Categories in desktop files? /usr/share/applications # grep Categories *desktop | head MozillaFirefox.desktop:Categories=Application;Network;WebBrowser;X-Ximian-Main;X-Ximian-Toplevel;GTK Xkill.desktop:Categories=X-SuSE-DesktopUtility Xrefresh.desktop:Categories=X-SuSE-DesktopUtility YaST.desktop:Categories=SystemSetup;X-SuSE-Core-System base.desktop:Categories=Office;Database; calc.desktop:Categories=Office;Spreadsheet; draw.desktop:Categories=Graphics;VectorGraphics; -- Richard Bos Without a home the journey is endless - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-factory] Packagage Groupings - From Selections in 10.1 to Patterns in 10.2
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Klaus Kaempf wrote: > * Pascal Bleser <[EMAIL PROTECTED]> [Jul 23. 2006 12:42]: > [...] >> Now, with those patterns, if they're not a closed, well-defined list of >> options to choose from, we will most probably end up with chaos. > > Well, actually I don't think so. We'll probably get as much (or better > as less) chaos as with packages. I think we have a slightly different view/understanding of the patterns. To me, it's not as much high-level packages than rather groups. I rather see the analogy with RPM Groups or .desktop categories. btw, just to make sure I got that right, can patterns be organized into a tree (i.e. do they have a hierarchy) ? e.g. Development/Database/Server > Patterns is about the ability to group packages for better overview > and handling, mostly at the UI level. Its an abstraction level. It's grouping... I wouldn't call that an "abstraction level" though :) An "abstraction", to me, would rather be to say "install texteditor" and you would get kate, emacs, vim or whatever ;) > However, I do agree that some kind of public 'pattern database' would > be nice in order to find duplicates and overlaps. Totally. I really see a risk of ending up with chaos here. To continue on my analogy with RPM groups and .desktop categories: if we didn't have a closed set of options to choose from (as defined in the SUSE Package Conventions), it would be havoc and the end-user KDE/GNOME menus wouldn't be very deep. At the very least, let's keep a pattern database (or rather, just a list) to try to reuse existing patterns if they match. ... >>> - The groups can be specified as comment-metadata at the top of the spec >>> file >> Well.. yeah... that should be the last option to consider. >> Introducing proprietary spec file tags through comments is really, >> really bad practice. > > I fully agree. The package-pattern relationship is not an attribute > of the package. > >> Anyhow, that pattern infrastructure must be "pluggable" - i.e. every >> package must be able to define what pattern it is part of. > > Please let the patterns define which packages they want. Grouping of > packages is already done with RPM groups. Being able to specify multiple > groups would be nice. Right. > But this does not specify (hard or weak) dependencies and there's > no use in enforcing specific package groups to be installed. However > with patterns, defining a functionality, dependencies express to-be- > installed packages and the dependency solver ensures this. Makes sense. If patterns were hard dependencies, then we could achieve the same with packages (and Requires:). >> I think it would be much better to just store the information directly >> in .pat files in repositories (in suse/setup/descr), in a simple format, >> to just create or modify those files with a simple text editor (XML >> would be an option as well - less human-readable/editable but validation >> would be a plus). > > Agreed. Lets create a 'pattern definition format' (just like .spec is a > package definition format) Yes please :) >> An example: >> - - you have two repositories configured in your list: SUSE Linux 10.2 and >> Packman (for SUSE Linux 10.2) >> - - in the SL 10.2 repository, in suse/setup/descr/, you have a file >> called "development-database-server.pat", that includes stuff like >> mysql, mysql-Max, postgresql-server, ...) >> - - in the Packman repository, in suse/setup/descr/, you also have a file >> called "development-database-server.pat", that includes e.g. firebird > > Well, thats similar to packages having the same name but different content. Mmmm... I don't agree ;) >> YaST2 must be capable of iterating through all the .pat files of all the >> repositories it has in its configuration, and to merge to actual list of >> packages that are part of each pattern from all of those. >> >> For the example above, the "Development/Database/Server" pattern should >> contain/show >> - - mysql >> - - mysql-Max >> - - postgresql-server >> - - firebird > > Given the package analogy above, would such a merge behaviour make sense ? I don't see any package analogy here with the patterns. It's just that if you see it as an analogy to RPM Groups or .desktop categories, a package that's in my repository (or packman, or ...) should be able to merge into a pattern/group/category that's already present on the SUSE repository (or media), as in the example above. >> On another note, I hope the process and behavior will be well-documented. >> It would be really neat to also implement pattern support into smart, >> for example. >> smart upgrade pattern:Desktop/KDE3 > > 'rug' is already able to do exactly this ;-) Ok, but I'd love to see it in smart ;)) Thanks for the feedback and information ! cheers - -- -o) Pascal Bleser http://linux01.gwdg.de/~pbleser/ /\\ <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> _\_v The more things change, the more they stay insane. -BEGIN PGP S
Re: [opensuse-factory] Packagage Groupings - From Selections in 10.1 to Patterns in 10.2
* jdd <[EMAIL PROTECTED]> [Jul 25. 2006 19:00]: > > patterns are more like categories in the wiki, only > informational. If one looks for a text editor, he should not > have to look at "writers" "editors" text processors", but > only at one of them. several nearby words can exist, but > hopefully with a clear difference in the meaning (editor > versus word processor or publisher) Sounds more like a list of keywords one can select from and the pattern manager computes the 'best match'. This would be quite a nice feature. Klaus - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-factory] YaST2 package upgrade operation (was: Packagage Groupings...)
* Pascal Bleser <[EMAIL PROTECTED]> [Jul 23. 2006 12:50]: > > I totally agree, upgrading packages is a major pain. Its mostly caused by historical reasons. Our main focus was on controlled (and controllable) customer environments for support purposes. Giving the user the ability to upgrade whatever package from any repository was (and still is) a supporters nightmare ;-) And this is still true for most enterprise systems. Sysadmins will never upgrade because a newer version is available but only because of a fixed bug or a required feature. > > IMO upgrading packages should be a one-click, show a proposal, give the > option to deselect some upgrade operations (if needed), and then a > confirmation button, that's it. zen-updater (and 'rug' on the command line) give you this ability. Klaus - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-factory] Packagage Groupings - From Selections in 10.1 to Patterns in 10.2
Klaus Kaempf a écrit : * jdd <[EMAIL PROTECTED]> [Jul 23. 2006 14:57]: Pascal Bleser wrote: Now, with those patterns, if they're not a closed, well-defined list of options to choose from, we will most probably end up with chaos. this point deserve to be better seen. It's probably essential to have a closed set of patterns. We can (we must :-) discuss _before_ launching the system, but after that the modification of the pattern list should be very difficult. Think of patterns as of packages. By adding an external repo, extending the patterns list should be fairly easy. Of course, the same traps as with packages exist. One can't prevent name (or content) clashes. But you can minimize them by being as open as possible. Klaus it's not the problem I was addressing. Packages have content, two packages of similar names can have very different coding. patterns are more like categories in the wiki, only informational. If one looks for a text editor, he should not have to look at "writers" "editors" text processors", but only at one of them. several nearby words can exist, but hopefully with a clear difference in the meaning (editor versus word processor or publisher) jdd -- http://www.dodin.net http://dodin.org/galerie_photo_web/expo/index.html http://lucien.dodin.net http://fr.susewiki.org/index.php?title=Gérer_ses_photos - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-factory] Packagage Groupings - From Selections in 10.1 to Patterns in 10.2
* Pascal Bleser <[EMAIL PROTECTED]> [Jul 23. 2006 12:46]: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Klaus Kaempf wrote: > > * James Oakley <[EMAIL PROTECTED]> [Jul 12. 2006 16:44]: > >> You could also use this to select tasks independently of the desktop > >> environment. If you select "Productivity/Chat" and you have KDE and GNOME > >> selected, you would get Konversation and XChat, but if you just have KDE, > >> you > >> would just get Konversation. > > > > Thats already possible with patterns. > > Could you give some more details about how it is or will be implemented ? With the 'freshens' and 'supplements' dependencies. 'Freshens' acts like a condition. If the frehens dependency is fulfilled (package/pattern being installed or to-be-installed), the supplements dependency is evaluated. So in the above example, Konversation would freshen the KDE pattern. > > In patterns, you can also define references to other patterns or > packages to elect installation candidates ? Yes. But dependencies are only possible from the higher to an equal or lower abstraction level. So a pattern can only depend on another pattern or a package. But a package cannot depend on a pattern. Klaus - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-factory] Packagage Groupings - From Selections in 10.1 to Patterns in 10.2
* jdd <[EMAIL PROTECTED]> [Jul 23. 2006 14:57]: > Pascal Bleser wrote: > > >Now, with those patterns, if they're not a closed, well-defined list of > >options to choose from, we will most probably end up with chaos. > > this point deserve to be better seen. > > It's probably essential to have a closed set of patterns. We > can (we must :-) discuss _before_ launching the system, but > after that the modification of the pattern list should be > very difficult. Think of patterns as of packages. By adding an external repo, extending the patterns list should be fairly easy. Of course, the same traps as with packages exist. One can't prevent name (or content) clashes. But you can minimize them by being as open as possible. Klaus - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-factory] Packagage Groupings - From Selections in 10.1 to Patterns in 10.2
* Pascal Bleser <[EMAIL PROTECTED]> [Jul 23. 2006 12:42]: [...] > > Now, with those patterns, if they're not a closed, well-defined list of > options to choose from, we will most probably end up with chaos. Well, actually I don't think so. We'll probably get as much (or better as less) chaos as with packages. Patterns is about the ability to group packages for better overview and handling, mostly at the UI level. Its an abstraction level. However, I do agree that some kind of public 'pattern database' would be nice in order to find duplicates and overlaps. Consider pattern P requiring package a,b,c,d and e. And pattern Q requiring a,b,c,d and f. With a database, one could see the a,b,c,d overlap, create a pattern R with a,b,c,d and let P require R and e and Q require R and f. > > > - The groups can be specified as comment-metadata at the top of the spec > > file > > Well.. yeah... that should be the last option to consider. > Introducing proprietary spec file tags through comments is really, > really bad practice. I fully agree. The package-pattern relationship is not an attribute of the package. > > Anyhow, that pattern infrastructure must be "pluggable" - i.e. every > package must be able to define what pattern it is part of. Please let the patterns define which packages they want. Grouping of packages is already done with RPM groups. Being able to specify multiple groups would be nice. But this does not specify (hard or weak) dependencies and there's no use in enforcing specific package groups to be installed. However with patterns, defining a functionality, dependencies express to-be- installed packages and the dependency solver ensures this. > > I think it would be much better to just store the information directly > in .pat files in repositories (in suse/setup/descr), in a simple format, > to just create or modify those files with a simple text editor (XML > would be an option as well - less human-readable/editable but validation > would be a plus). Agreed. Lets create a 'pattern definition format' (just like .spec is a package definition format) > > An example: > - - you have two repositories configured in your list: SUSE Linux 10.2 and > Packman (for SUSE Linux 10.2) > - - in the SL 10.2 repository, in suse/setup/descr/, you have a file > called "development-database-server.pat", that includes stuff like > mysql, mysql-Max, postgresql-server, ...) > - - in the Packman repository, in suse/setup/descr/, you also have a file > called "development-database-server.pat", that includes e.g. firebird Well, thats similar to packages having the same name but different content. > > YaST2 must be capable of iterating through all the .pat files of all the > repositories it has in its configuration, and to merge to actual list of > packages that are part of each pattern from all of those. > > For the example above, the "Development/Database/Server" pattern should > contain/show > - - mysql > - - mysql-Max > - - postgresql-server > - - firebird Given the package analogy above, would such a merge behaviour make sense ? > > On another note, I hope the process and behavior will be well-documented. > It would be really neat to also implement pattern support into smart, > for example. > smart upgrade pattern:Desktop/KDE3 'rug' is already able to do exactly this ;-) Klaus - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-factory] Unmantained package ladspa
2006/7/25, jdd <[EMAIL PROTECTED]>: Juan Erbes wrote: >> From 3 mohnts ago, I could'nt use audacity because with any version >> (1.24b, > > 1.3 beta, 1.3.1beta cvs), it hangs (precompiled or compiled by me). > The last weekend, I debuguing it with ddd and gdb, and I found that the > hang > comes with triangle librarie from the ladspa plugins. Then I recompiled > audacity without ladspa, and it not hangs any more. > > I tryed to compile ladspa, but I found that the last version is from dec > 2002 (version 1.15), and the version compiled by suse, is 1.12. Then, i > mean > that this package are unmantained. > > Thanks > audacity from 10.1 works for me, but it's extremely buggy (french translation unusable, cursor jumping, sound lag) With the 10.1 I have'nt problems with audacity. The problem with audacity (ladspa) is in the actual alpha 10.2 OSS. Regards
Re: [opensuse-factory] Unmantained package ladspa
On Tue, Jul 25, 2006 at 08:52:13AM -0300, Juan Erbes wrote: > >From 3 mohnts ago, I could'nt use audacity because with any version (1.24b, > 1.3 beta, 1.3.1beta cvs), it hangs (precompiled or compiled by me). > The last weekend, I debuguing it with ddd and gdb, and I found that the hang > comes with triangle librarie from the ladspa plugins. Then I recompiled > audacity without ladspa, and it not hangs any more. > > I tryed to compile ladspa, but I found that the last version is from dec > 2002 (version 1.15), and the version compiled by suse, is 1.12. Then, i mean > that this package are unmantained. Please open an "Enhancement" bugreport in such cases. Ciao, Marcus - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-factory] Unmantained package ladspa
Juan Erbes wrote: From 3 mohnts ago, I could'nt use audacity because with any version (1.24b, 1.3 beta, 1.3.1beta cvs), it hangs (precompiled or compiled by me). The last weekend, I debuguing it with ddd and gdb, and I found that the hang comes with triangle librarie from the ladspa plugins. Then I recompiled audacity without ladspa, and it not hangs any more. I tryed to compile ladspa, but I found that the last version is from dec 2002 (version 1.15), and the version compiled by suse, is 1.12. Then, i mean that this package are unmantained. Thanks audacity from 10.1 works for me, but it's extremely buggy (french translation unusable, cursor jumping, sound lag) jdd -- http://www.dodin.net http://dodin.org/galerie_photo_web/expo/index.html http://lucien.dodin.net http://fr.susewiki.org/index.php?title=Gérer_ses_photos - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[opensuse-factory] Unmantained package ladspa
From 3 mohnts ago, I could'nt use audacity because with any version (1.24b, 1.3 beta, 1.3.1beta cvs), it hangs (precompiled or compiled by me). The last weekend, I debuguing it with ddd and gdb, and I found that the hang comes with triangle librarie from the ladspa plugins. Then I recompiled audacity without ladspa, and it not hangs any more. I tryed to compile ladspa, but I found that the last version is from dec 2002 (version 1.15), and the version compiled by suse, is 1.12. Then, i mean that this package are unmantained. Thanks
Re: [opensuse-factory] Public YOU testing / Broken YOUs + avoiding them
On Mon, Jul 24, 2006 at 11:03:38PM +0200, Andreas Hanke wrote: > Hi, > > I'm currently a little bit disappointed of > > https://bugzilla.novell.com/show_bug.cgi?id=192743 > > and its duplicate > > https://bugzilla.novell.com/show_bug.cgi?id=193996 > > which is caused by a broken YOU for SUSE Linux 10.0. This is totally unrelated to YaST Online Update. It might be related to a specific kdebase3-SUSE update. > The background and a fix are available at > > http://people.opera.com/eddy/YaST/ReadMe.html > > and the bug is a frustrating one since I know some people who stuck with > 10.0 because installing RPMs with YaST from Konqueror is not possible in > 10.1, and now after this YOU it's broken for 10.0 as well. > > More generally, I'd like to know if it would be possible to do public > tests for *all* YOUs (maybe except not-yet-disclosed security fixes). We > had it in the past for a subset of selected packages like the libzypp > and kernel YOUs, and it worked quite well so far. I have considered and asked for this, but so far this was not possible due to SUSE internal constraints. > I remember some problematic YOUs in the past and now I just wonder if a > different testing approach might eventually help improving the > situation. The Fedora project seems to have a similar approach that > could be used to borrow ideas from. I have the idea for a year now. Ciao, Marcus - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-factory] updating m4 package from factory
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Andreas Hanke escribió: > To answer your question: Factory is not guaranteed to be always consistent. > > See also: http://en.opensuse.org/Factory > > For example, it can happen that a package is updated in such a way that > dependent packages have to be updated as well, but the updated packages > of the dependent packages don't build. > > This will probably always happen from time to time and disappear again > shortly afterwards. > Hi Andreas: OK,It is all clear at this moment. Now I know I must check my upgrades or updates from factory searching inconsistencies... Thanks and regards - -- Chema Ollés Usuario Linux: #198057 Linux 2.6.16.21-2-smp #1 SMP Wed Jul 5 17:47:38 UTC 2006 i686 GNU/Linux -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.4 (GNU/Linux) iD8DBQFExdUP65SpD7GhbzoRAp40AKC8RNCa1r4Xvej8ZY4hLEWdtosLCQCgkDYn neC3vJip2IoRcYbwAGhAbSk= =y7VP -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
