Re: [opensuse-factory] Re: Announcing Yast-GTK (forw)
> >And while you are at it: Can the next SoC project please remove the > >gnome dependencies from zen (and other system services) and offer qt/kde > >alternatives for those who only want to run a kde desktop? > > Forget it. That would require that someone writes a qt# library and > possibly kde# libraries first in order to then rewrite zmd and other > zen stuff thats written in mono. That someone would then have to > constantly maintain all the stuff. IMNSHO that's never going to > happen. That looks to me like that in a lot of peoples' opinion, the "forget it" also applies to novell-zen: there's little interest in running a desktop (esp gnome) just for basic system services. Billy made that mistake many years ago, and boy fell he on his face. Volker -- Volker Kuhlmann is list0570 with the domain in header http://volker.dnsalias.net/ Please do not CC list postings to me. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[opensuse-factory] Re: Announcing Yast-GTK (forw)
On Fri, 25 Aug 2006 10:00:05 +0200, Joerg Mayer wrote: >Date: Fri, 25 Aug 2006 09:58:47 +0200 >From: Joerg Mayer <[EMAIL PROTECTED]> >To: Marcel Hilzinger <[EMAIL PROTECTED]> >Subject: Re: [opensuse-factory] Announcing Yast-GTK >In-Reply-To: <[EMAIL PROTECTED]> You don't quote headers! >And while you are at it: Can the next SoC project please remove the >gnome dependencies from zen (and other system services) and offer qt/kde >alternatives for those who only want to run a kde desktop? Forget it. That would require that someone writes a qt# library and possibly kde# libraries first in order to then rewrite zmd and other zen stuff thats written in mono. That someone would then have to constantly maintain all the stuff. IMNSHO that's never going to happen. Philipp - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-factory] openSUSE 10.2 Features and Roadmap
Hi, Andreas Jaeger schrieb: >> YaST-gtk? > > It might be in Alpha4 but I consider it too early to announce it. Please wait before including it. I really like yast2-gtk, I appreciate Ricardo's work and don't want to criticize it unfairly in his absense, but it must be 100% ready and stable before it can be included. YaST's reputation is seriously damaged because of the problems with 10.1 and I'm not sure about the impact of including yast2-gtk now. Users have very high expectations about 10.2. They want to have an almost perfect YaST, not only in software stability, but also in UI stability and continuity. Including another frontend now might show the world something false and strange like "we're creating new frontends while there are serious functionality and performance problems to be fixed". Of course it's not true, because the frontend and the underlying libraries are made by different people. But please consider what people think. The first reaction to Ricardo's announcement was: "Just out of interest, what is the advantage of re-implementing yast by linking it with libgtk instead of libqt? Wouldn't the time have been better spent improving yast itself?" http://lists.opensuse.org/archive/opensuse-factory/2006-08/msg00403.html It's the reaction I expected. GNOME users can actually live with the Qt frontend, they have been able to live with it for years and it did not hurt that much. Maybe it can be included, but not yet installed by default so it becomes an opt-in offering for now, like Xgl. Once YaST itself restored its reputation, a new frontend will have better acceptance. We should in any case avoid the impression that new stuff is included prematurely. Andreas Hanke - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-factory] SL-Factory vs. SL-Factory-debug
Hi, On Fri, 25 Aug 2006, Andreas Hanke wrote: Andreas Hanke schrieb: - Separate repositories for source packages - bad idea IMHO. Why do you think this is a bad idea ? Because they would be harder to find, resulting in fake GPL violation discussions on this list :-( Another point to consider: If it becomes possible to mirror the distribution without the source RPMs, someone will do it; and if someone does it, people will come back here and ask why there are just binaries on a mirror and not the sources. Brute-forcing mirrors to have the source RPMs by tying them together with the binary RPMs is a desirable effect IMHO. Serving fools just creates a new fool. So this should not be an "originary" aspect. Cheers -e -- Eberhard Moenkeberg ([EMAIL PROTECTED], [EMAIL PROTECTED]) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-factory] SL-Factory vs. SL-Factory-debug
Andreas Hanke schrieb: >>> - Separate repositories for source packages - bad idea IMHO. >> >> Why do you think this is a bad idea ? > > Because they would be harder to find, resulting in fake GPL violation > discussions on this list :-( Another point to consider: If it becomes possible to mirror the distribution without the source RPMs, someone will do it; and if someone does it, people will come back here and ask why there are just binaries on a mirror and not the sources. Brute-forcing mirrors to have the source RPMs by tying them together with the binary RPMs is a desirable effect IMHO. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-factory] SL-Factory vs. SL-Factory-debug
* Andreas Hanke <[EMAIL PROTECTED]> [Aug 25. 2006 16:24]: > Hi, > > Klaus Kaempf schrieb: > >> - Separate repositories per architecture - not possible because SUSE > >> repositories have always been multiarch. > > > > It not impossible, but needs extra work. Currently its also nice to > > publish only one repo URL without the need to distinguish between > > different architectures. > > And there would have to be a solution for biarch - because x86_64 needs > to know about the i586 packages. All of them ? Probably not. But it might be too much work to calculate needed (like 32 bit libraries) one. > > Are the metadata of source packages faster or slower or equal to parse? > Do they have equally verbose dependency information? They are faster to parse because they usually have no dependency information. Klaus - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-factory] SL-Factory vs. SL-Factory-debug
Hi, Klaus Kaempf schrieb: >> - Separate repositories per architecture - not possible because SUSE >> repositories have always been multiarch. > > It not impossible, but needs extra work. Currently its also nice to > publish only one repo URL without the need to distinguish between > different architectures. And there would have to be a solution for biarch - because x86_64 needs to know about the i586 packages. Fedora seems to solve this by duplicating even the i386 packages in addition to the noarch packages: http://download.fedora.redhat.com/pub/fedora/linux/core/development/x86_64/os/Fedora/RPMS/ I see a lot of i386 RPMs in that directory. It's not exactly a nicer solution than ours, however. In other words, it's ugly ;-) Furthermore, yum is able to expand the $basearch variable automatically, so there is still a single repository URL using this variable. >> - Separate repositories for source packages - bad idea IMHO. > > Why do you think this is a bad idea ? Because they would be harder to find, resulting in fake GPL violation discussions on this list :-( I thought about proposing that the source packages are handled together with the debuginfo packages, because they are both interesting for developers. But the source packages are a special case because some users tend to get angry if they don't find them easily. And the number of source packages does not increase when adding new architectures, but the number of debuginfo packages does. Are the metadata of source packages faster or slower or equal to parse? Do they have equally verbose dependency information? At least they don't seem to have equally verbose filelist information. There is filelist information for source packages in filelists.xml, but most source packages don't have that many sources and patches in them. Andreas Hanke - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-factory] SL-Factory vs. SL-Factory-debug
* Andreas Hanke <[EMAIL PROTECTED]> [Aug 25. 2006 15:24]: [...] > 22000 total packages in a SINGLE repository. > > Fedora: > > 2200 packages in the repository most people are interested in (i586 > binary + noarch, no debuginfo, no source, no other architectures). > > 22000/2200 is a factor of 10! Yes, this is one of the problems we're facing. > > This makes me seriously doubt that rpm-md is designed or even suitable > for such huge repositories. It's not surprising that parsing this beast > is slow, even with a fast parser. It also makes me doubt that improving > the parser is the only way of approaching the problem. > > So I thought how to reduce the number of packages: > > - Separate repositories per architecture - not possible because SUSE > repositories have always been multiarch. It not impossible, but needs extra work. Currently its also nice to publish only one repo URL without the need to distinguish between different architectures. > > - Separate repositories for source packages - bad idea IMHO. Why do you think this is a bad idea ? > > - Reducing the number of packages - not possible, people want to have > more software and not less. Reducing the number of packages _per_ repository is easily possible. If you want more software, add more repositories. The OpenSUSE build service is supposed to address this in the future. What we need is some kind of 'meta repository' which points to other repositories. Its planned but we do not know if its doable in the OpenSUSE 10.2 timeframe. Klaus - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-factory] SL-Factory vs. SL-Factory-debug
Andreas Hanke <[EMAIL PROTECTED]> writes: > [...] > This makes me seriously doubt that rpm-md is designed or even suitable > for such huge repositories. It's not surprising that parsing this beast > is slow, even with a fast parser. It also makes me doubt that improving > the parser is the only way of approaching the problem. I agree with this conclusion. xml is nice but it shows it limits here. > So I thought how to reduce the number of packages: > > - Separate repositories per architecture - not possible because SUSE > repositories have always been multiarch. We could - no problem at all. It would increase the space since all source and noarch packages would need to be duplicated. We love to have one ;-) > - Separate repositories for source packages - bad idea IMHO. > > - Reducing the number of packages - not possible, people want to have > more software and not less. > > The debuginfo packages sounded like a reasonable candidate to me because > their number is always proportional to the number of binary packages. If > we get a new architecture like ia64, we get more debuginfo packages as > well, which means we can also save proportionally by splitting them from > the rest. > > Note also that we already have performance workarounds. Using the old > susetags metadata instead of rpm-md during initial installation is one > of them. 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 pgpKJ5N9qU5ek.pgp Description: PGP signature
[opensuse-factory] FIXED: Apt searching scripts in the wrong place
* Manfred Hollstein ([EMAIL PROTECTED]) [20060817 14:31]: > 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. I've fixed this bug now. The fixed package will hopefully be in the next 10.2 alpha. I've also uploaded fixed packages for 10.0 and 10.1 to ftp.suse.com/pub/people/pth. You'll find them in 10.0-i386, 10.0-x86_64, 10.1-i386 and 10.1-x86_64. Philipp - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-factory] SL-Factory vs. SL-Factory-debug
Hi, Joerg Mayer schrieb: > OK, so you are proposing a *workaround* for a known and very severe > problem. Especially with factory, we should *not* concentrate on > workaround but on *fixes*! So as long as factory is a development > branch, this *should not* be done. Joerg, this is a valid point if it were a workaround, but it is not entirely a workaround. Do you know any other distro that has such a huge package base as openSUSE and uses rpm-md? I don't. Before making the proposal, I looked at Fedora's repository layout and found out the following: - Fedora Core has significantly fewer packages than openSUSE. - Fedora already splits the debuginfo packages out, into a separate directory that doesn't have any repository metadata at all. - Fedora also separates the repositories per architecture even though rpm-md supports multiarch repositories very well. - Fedora splits the source packages into a separate repository from the binary packages. In numbers. openSUSE: 4000 "real" i586 binary packages. 2000 i586 debuginfo packages. 4000 "real" x86_64 binary packages. 2000 x86_64 debuginfo packages. 4000 "real" ppc binary packages. 2000 ppc debuginfo packages. 1000 noarch packages. 3000 source packages. 22000 total packages in a SINGLE repository. Fedora: 2200 packages in the repository most people are interested in (i586 binary + noarch, no debuginfo, no source, no other architectures). 22000/2200 is a factor of 10! This makes me seriously doubt that rpm-md is designed or even suitable for such huge repositories. It's not surprising that parsing this beast is slow, even with a fast parser. It also makes me doubt that improving the parser is the only way of approaching the problem. So I thought how to reduce the number of packages: - Separate repositories per architecture - not possible because SUSE repositories have always been multiarch. - Separate repositories for source packages - bad idea IMHO. - Reducing the number of packages - not possible, people want to have more software and not less. The debuginfo packages sounded like a reasonable candidate to me because their number is always proportional to the number of binary packages. If we get a new architecture like ia64, we get more debuginfo packages as well, which means we can also save proportionally by splitting them from the rest. Note also that we already have performance workarounds. Using the old susetags metadata instead of rpm-md during initial installation is one of them. Andreas Hanke - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-factory] openSUSE 10.2 Features and Roadmap
Martin Schlander <[EMAIL PROTECTED]> writes: > Fredag 25 august 2006 13:36 skrev Andreas Jaeger: >> The upcoming openSUSE 10.2 will basically have similar content like >> its predecessor but comes of course with latest and stable Open Source >> packages available at that time. We went through Bugzilla, the >> feature list and package wishlist and try to accomodate your wishes >> and suggestions. >> >> Note that the list below is neither complete - it's just some of the >> highlights - nor a commitment. > > Sounds great to me. Looks like all significant issues are being adressed, > this > could turn out to be a distro so great that it'll more than compensate for > the horrors we've been going through with 10.1 ;) > > Just a couple of quick questions.. > > KDE 3.5.5 (October 10th, 2006: Expected release date of KDE 3.5.5)? I should have looked better - yes, this is an option and I assume it goes in. > Narayans KDE zmd-updater applet? Yes, considered. The list is really not complete. > Aiglx? Not planned. > YaST-gtk? It might be in Alpha4 but I consider it too early to announce it. 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 pgpChsfdHBvXM.pgp Description: PGP signature
Re: [opensuse-factory] openSUSE 10.2 Features and Roadmap
On Fri, Aug 25, 2006 at 02:29:25PM +0200, Martin Schlander wrote:
> Just a couple of quick questions..
>
> Aiglx?
Well, our experiences have not been the best:
(tried with xorg-server-7.1.99.3/i810-1.6.5 on 915G)
- X Server log:
(WW) AIGLX: 3D driver claims to not support visual 0x23
[...]
(WW) AIGLX: 3D driver claims to not support visual 0x32
- compiz: No stencil buffer. Clipping of transformed windows is
not going to be correct when screen is transformed.
--> desktop looks broken and is no longer usable
You can enable it ('Option "AIGLX" "true"' in ServerFlags section of
xorg.conf)- if you want and play with it. Good luck! And don't forget
to enable Composite extension as well - which is known to be broken at
least for some drivers, e.g. "fglrx". Others might consider to use Xgl
instead as before. :-)
> Now, if only we could somehow have KMPs for ATi and Nvidia available, we
> needn't worry about Vista at all..
I can't comment on openSUSE 10.2 (probably nobody can ATM), but for
openSUSE 10.1 this is already in place - thanks to the common code
base of SL 10.1/SLE10.
Best regards,
Stefan
Public Key available
--
Stefan Dirsch (Res. & Dev.) SUSE LINUX Products GmbH
Tel: 0911-740 53 0Maxfeldstraße 5
FAX: 0911-740 53 479 D-90409 Nürnberg
http://www.suse.deGermany
--
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-factory] openSUSE 10.2 Features and Roadmap
i think YaST-gtk whould be greatOn 8/25/06, Martin Schlander <[EMAIL PROTECTED]> wrote: Fredag 25 august 2006 13:36 skrev Andreas Jaeger:> The upcoming openSUSE 10.2 will basically have similar content like> its predecessor but comes of course with latest and stable Open Source> packages available at that time. We went through Bugzilla, the > feature list and package wishlist and try to accomodate your wishes> and suggestions.>> Note that the list below is neither complete - it's just some of the> highlights - nor a commitment. Sounds great to me. Looks like all significant issues are being adressed, thiscould turn out to be a distro so great that it'll more than compensate forthe horrors we've been going through with 10.1 ;) Just a couple of quick questions..KDE 3.5.5 (October 10th, 2006: Expected release date of KDE 3.5.5)?Narayans KDE zmd-updater applet?Aiglx?YaST-gtk?Now, if only we could somehow have KMPs for ATi and Nvidia available, we needn't worry about Vista at all..Martin-To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]-- with best regards from Russia
Re: [opensuse-factory] openSUSE 10.2 Features and Roadmap
Fredag 25 august 2006 13:36 skrev Andreas Jaeger: > The upcoming openSUSE 10.2 will basically have similar content like > its predecessor but comes of course with latest and stable Open Source > packages available at that time. We went through Bugzilla, the > feature list and package wishlist and try to accomodate your wishes > and suggestions. > > Note that the list below is neither complete - it's just some of the > highlights - nor a commitment. Sounds great to me. Looks like all significant issues are being adressed, this could turn out to be a distro so great that it'll more than compensate for the horrors we've been going through with 10.1 ;) Just a couple of quick questions.. KDE 3.5.5 (October 10th, 2006: Expected release date of KDE 3.5.5)? Narayans KDE zmd-updater applet? Aiglx? YaST-gtk? Now, if only we could somehow have KMPs for ATi and Nvidia available, we needn't worry about Vista at all.. Martin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[opensuse-factory] openSUSE 10.2 Features and Roadmap
Michael Löffler is currently on vacation and asked me to discuss the following, it's based on his latest draft. All errors are mine naturally ;-) The upcoming openSUSE 10.2 will basically have similar content like its predecessor but comes of course with latest and stable Open Source packages available at that time. We went through Bugzilla, the feature list and package wishlist and try to accomodate your wishes and suggestions. Note that the list below is neither complete - it's just some of the highlights - nor a commitment. Here an overview about areas we like to enhance, change or add things: System & Software Management - Performance enhancements with software management rug, libzypp - Support hardware with SW-RAID support in BIOS - Biometrical authentification - X.org 11R7.1 - Kernel 2.6.18 - install local rpm(s) with dependency checking and to register directory as YaST source, Bug 174369, 168358 - add a button to YaST/zen-installer to add interesting installation sources like freshmeat, sourceforge, packman etc. - SUSEfirewall2, description of the ports and and ability to open or close ports - Moving from software selections to patterns as grouping of packages Desktop & Productivity Software - Gnome 2.16, with new menue out of SUSE Linux Enterprise - KDE 3.5.4 , with polished menue - adding VoIP solution Ekiga (formely known Gnome Meeting), Bug 147517 - support for rt2500 wlan card, Bug 149141 - add Intels 3D open source driver - adding Broadcom WLAN support Commercial software - adding Wink, software for creating video tutorials and export them to flash, http://www.debugmode.com/wink/ (free software, available for Linux as well) - GoogleEarth, we try to get redistribution rights from Google Please give feedback and of course if there's something missing - tell us. ~~ Schedule openSUSE 10.2 Here's the openSUSE 10.2 schedule as aligned with holidays, other deliverables etc. I'm always writing the dates of the planned public releases and what I associate with the milestones. I'll further refine the milestones a bit to define which changes are allowed until which time. We have staged freezes which means that the first packages will be feature frozen with Alpha5 - the last ones shortly after Beta1. Note, below are the public dates for the *release*, the package submission deadlines are a couple of days earlier and not added. -- Thu, Oct 05 openSUSE 10.2 Alpha5 release - installation, toolchain, component, crypto freeze * Milestone: Toolchain, installation workflow are feature frozen * Milestone: Packages containing cryptographic routines are frozen * Milestone: First round for software translation * Milestone: Component freeze: Major updates and addition of subsystems finished. -- Thu, Oct 19 openSUSE 10.2 Alpha5+ release (internal) * Milestone: Documentation deadline, proofing starts * Milestone: Feature and version freeze for the base system * Milestone: Kernel and install works on most targeted machines. -- Fri, Oct 20 * Milestone: First round of software translation finished. * Packagers start integration translations into packages for Beta1 -- Thu, Oct 26 openSUSE 10.2 Beta1 release (feature complete) * Milestone: Feature and version freeze for the complete distribution (exception: patchlevel update of leaf packages until Nov 4) * Milestone: First localized build * Milestone: Complete string freeze * Milestone: All features are coding and function complete. * Milestone: Kernel and install works on all targeted machines. * Milestone: Last round of software translation starts -- Fri, Nov 4 - 1pm CET * Milestone: Final round of software translation finished. * Packagers start integration translations into packages for Beta2 * Milestone: Patchlevel update of leaf packages finished. -- Thu, Nov 9 openSUSE 10.2 Beta2 release * Milestone: Fully localized build * Milestone: Localization testing starts * Milestone: Only major/critical/blocker bugfixes allowed. -- Fri, Nov 17 - 1pm CET * Milestone: Fixes found during localization testing returned. * Packagers start integration translations into packages for RC1 * Milestone: Only blocker bugfixes allowed. -- Thu, Nov 23 openSUSE 10.2 RC1 release * Milestone: All blocker bugs resolved. * Milestone: All documentat
Re: [opensuse-factory] SL-Factory vs. SL-Factory-debug
Peter Czanik <[EMAIL PROTECTED]> writes: > [...] > Related question: do you know anything about when fixes introduced here: > https://bugzilla.novell.com/show_bug.cgi?id=201164 will hit the factory > repository? Installer files are still from 18th August, and thus > severely broken... With the next sync - Timo and myself briefly tested yesterday evening the packages and it worked fine, so expect it anytime now... 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 pgpIGLqedtlmW.pgp Description: PGP signature
Re: [opensuse-factory] SL-Factory vs. SL-Factory-debug
Andreas Hanke <[EMAIL PROTECTED]> writes: > [...] > For Factory, the ratio of people who need them is probably larger than > for a released version. The proposal was primarily intended for the > released versions. OK, now we have it for Factory, too. You have it for factory first ;-) Future repositories will have it, so expect it for 10.2 ... 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 pgpdJO0L3CYNo.pgp Description: PGP signature
Re: [opensuse-factory] SL-Factory vs. SL-Factory-debug
On Fri, Aug 25, 2006 at 10:45:56AM +0200, Adrian Schroeter wrote: > Basicaly two reasons: > > 1. Mirrors can skip the debuginfo packages, without an exclude rule and >without to "break" the repository meta data. > > 2. The installers have less meta data to handle by default (when you ignore >the -debug repo), this let them take less memory, faster downloads of the >meta data and faster solving. Thanks. I'd appreciate to see short explanations like this one in the first place when making announcements like this. Just saying "on popular request" did not sound as if the decission was really based on a reason. Robert -- Robert Schiele Tel.: +49-621-181-2214 Dipl.-Wirtsch.informatiker mailto:[EMAIL PROTECTED] "Quidquid latine dictum sit, altum sonatur." pgpbUfeLzxSsJ.pgp Description: PGP signature
Re: [opensuse-factory] SL-Factory vs. SL-Factory-debug
Am Friday 25 August 2006 04:14 schrieb Robert Schiele: > On Thu, Aug 24, 2006 at 06:01:14PM +0200, Adrian Schroeter wrote: > > Hi, > > > > on popular request, we separated the debuginfo packages from Factory into > > a separated repository. > > I wonder why I didn't catch a single one of these "popular requests" on > this mailing list. there were a number of bugzilla reports around this. > > We will have SL-OSS-Factory and SL-OSS-Factory-debug directories with the > > next sync. > > > > Users of the opensuse-full or opensuse-full-with-factory modules do not > > have to change anything. > > > > I hope this is fine with everybody. > > Well, actually in my opinion it is just more unconvenient to have all these > repository splits if you want to setup installation sources. I mean I can > understand the reason to separate the non-oss stuff to have an oss-clean > distribution. (Actually I still can't understand why non-oss stuff for > factory must be still hosted on suse.com whereas all other non-oss stuff is > now hosted on opensuse.org.) > > But what was the _reason_ for the debuginfo split? Just that some people > wanted to have it without having a reason? Or didn't they understand how > to use --exclude with rsync? Basicaly two reasons: 1. Mirrors can skip the debuginfo packages, without an exclude rule and without to "break" the repository meta data. 2. The installers have less meta data to handle by default (when you ignore the -debug repo), this let them take less memory, faster downloads of the meta data and faster solving. bye adrian -- 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] Announcing Yast-GTK (forw)
... because the reply-to on a discussion list is not pointing to the list - Forwarded message from Joerg Mayer <[EMAIL PROTECTED]> - Date: Fri, 25 Aug 2006 09:58:47 +0200 From: Joerg Mayer <[EMAIL PROTECTED]> To: Marcel Hilzinger <[EMAIL PROTECTED]> Subject: Re: [opensuse-factory] Announcing Yast-GTK In-Reply-To: <[EMAIL PROTECTED]> On Wed, Aug 23, 2006 at 11:23:00AM +0200, Marcel Hilzinger wrote: > > Just out of interest, what is the advantage of re-implementing yast by > > linking it with libgtk instead of libqt? Wouldn't the time have been > > better spent improving yast itself? > > What's the advantage of having a qt and a gtk frontend for networkmanager? > And > having a qt and a gtk desktop at all? > > Give KDE users qt and Gnome users gkt ! And while you are at it: Can the next SoC project please remove the gnome dependencies from zen (and other system services) and offer qt/kde alternatives for those who only want to run a kde desktop? ciao Joerg -- Joerg Mayer <[EMAIL PROTECTED]> We are stuck with technology when what we really want is just stuff that works. Some say that should read Microsoft instead of technology. - End forwarded message - -- Joerg Mayer <[EMAIL PROTECTED]> We are stuck with technology when what we really want is just stuff that works. Some say that should read Microsoft instead of technology. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-factory] SL-Factory vs. SL-Factory-debug
On Fri, Aug 25, 2006 at 05:54:18AM +0200, Andreas Hanke wrote: > Someone has to parse all this stuff. I mean, the metadata. It is well > known that zypp parses the repository metadata slowly. It has already > become faster and it will become even better, but it's still slow. > > And it's not just zypp. Yum, with the new(!) C metadata parser written > by Tambet Ingo, needs half a minute to parse primary.xml and again half > a minute to parse filelists.xml on my laptop. I don't even want to know > how slow it would be with the old python parser. OK, so you are proposing a *workaround* for a known and very severe problem. Especially with factory, we should *not* concentrate on workaround but on *fixes*! So as long as factory is a development branch, this *should not* be done. ciao Joerg -- Joerg Mayer <[EMAIL PROTECTED]> We are stuck with technology when what we really want is just stuff that works. Some say that should read Microsoft instead of technology. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-factory] SL-Factory vs. SL-Factory-debug
Hello, Adrian Schröter írta: > on popular request, we separated the debuginfo packages from Factory into a > separated repository. > Thanks, this was a very good idea. Finally I don't need to use --exclude in rsync in my mirror scripts, and I hope, it will significantly decrease the RAM and CPU requirements of package parsing. Just a rough estimate: one third less package data to parse by YaST / libzypp. Once the installer is working again, I'll check out, if I can install factory again with 256MB of RAM without turning on swap from the command line :-) Related question: do you know anything about when fixes introduced here: https://bugzilla.novell.com/show_bug.cgi?id=201164 will hit the factory repository? Installer files are still from 18th August, and thus severely broken... Bye, CzP - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-factory] SL-Factory vs. SL-Factory-debug
Andreas Hanke <[EMAIL PROTECTED]> writes: > And it's not just zypp. Yum, with the new(!) C metadata parser written > by Tambet Ingo, needs half a minute to parse primary.xml and again half > a minute to parse filelists.xml on my laptop. I don't even want to know > how slow it would be with the old python parser. The horror! ;) Someone out there who has tried to store the data in an XML database system (dbxml, idzebra, etc.) and to access it from there? I do not understand why build the objects again and again. -- Karl Eichwalder R&D / Documentation SUSE Linux Products GmbH Key fingerprint = B2A3 AF2F CFC8 40B1 67EA 475A 5903 A21B 06EB 882E - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
