a couple of days ago there was a discussion about merging the rpm's for
kernel-default and kernel-smp. Did that already happen? I don't see
kernel-smp in the factory-repository anymore.
--
TIA
Andreas
---------------------------------------------------------------------
To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-factory+help(a)opensuse.org
On Tue, Aug 29, 2006 at 08:45:06AM -0300, Druid wrote:
> >
> >> 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.
>
>
> Already in place? You mean that using the sle kmp from nvidia repository,
Yes.
> which was broken when 10.1 got kernel update and sle didnt,
Really? Did we release a kernel update for 10.1, which we didn't
release for SLE10? Too bad.
> [...] (or will 10.1 and sle have kernel updates synced?
This was my assumption, yes.
> I dont think so, as it seems 10.1 is the testbed of your enterprise
> products) is actually a solution? I dont think so. If I cant update the
> nvidia kmp anyday I want (including the days when 10.1 get kernel updates
> and sle dont), then its not a working solution.
>
> Is it hard to make kmps for the opensuse releases? Or a financial hog? Or
> they dont want to?
>
> You cant answer for 10.2? I woud expect that the current method was
> maintained,
It's only maintained for SLE10. Fortunately 10.1/SLE10 use the same
code base. So you can use it by accident also for 10.1.
> since you form Novell just got an agreement of a method with
> nvidia to deliver their drivers. Or shoudl I expect it to change again? Will
> it change in every suse release? Maybe I should expect that in 10.2 I would
> need to run a command called "small-nvidia-updater -g"? Talk about common
> procedures...
I don't know either ...
Best regards,
Stefan
Public Key available
------------------------------------------------------
Stefan Dirsch (Res. & Dev.) SUSE LINUX Products GmbH
Tel: 0911-740 53 0 Maxfeldstraße 5
FAX: 0911-740 53 479 D-90409 Nürnberg
http://www.suse.de Germany
------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-factory+help(a)opensuse.org
I just tried to install 10.1 on this SATA system that was originally
cloned from PATA when I bought a new system with I915/ICH6 and a faster
CPU 17 months ago. Before the clone operation, 9.2 ran from /dev/hda16,
Mandriva from /dev/hda7, Knoppix from /dev/hda15, and windoz and OS/2
and data occupied various other partitions. Now the 10.1 installer gives
me these error messages:
-
WARNING: This system has at least one hard disk with a RAID configuration
presented by the BIOS as RAID that is in fact software RAID. The
following disks were detected as part of such RAID:
/dev/sda /dev/sdb
-
The Linux kernel 2.4 supported some of these systems (like Promise
FastTrack and
HighPoint RocketRaid), but the Linux kernel 2.6 does not support them at
all.
If you install onto these disks, your RAID configuration and any data
on the RAID will be lost. Refer to http://portal.suse.com to learn how to
migrate to a Linux software RAID.
-
-
Your disk /dev/sda contains 46 partitions. The maximum number
of partitions that the kernel driver of the disk can handle is 15.
Partitions numbered above 15 cannot be accessed.
-
Your disk /dev/sdb contains 19 partitions. The maximum number
of partitions that the kernel driver of the disk can handle is 15.
Partitions numbered above 15 cannot be accessed.
-
At the partitioning step, only those up to 15 were listed, and it
offered to delete most (mostly OS/2, which it erroneously calls windoz)
partitions. At that point I aborted the install, as I have all attempted
Linux installs on this system.
Surely people with SATA disks of upwards of 400G cannot be satisfied
with SCSI's device (partition) name limit of 14. When is this going to
be fixed. When is this problem going to be solved so that I can install
where 9.2 was installed, or anywhere else for that matter? When is the
kernel going to quit calling SATA SCSI? Wasn't it bad enough for the
system to content with real SCSI devices mixed with USB devices without
adding SATA into the mix? This SCSI/USB/SATA business is a mess.
--
"If you confess with your mouth, 'Jesus is Lord', and believe in
your heart that God raised him from the dead, you will be saved."
Romans 10:9 NIV
Team OS/2 ** Reg. Linux User #211409
Felix Miata *** http://mrmazda.no-ip.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: opensuse-factory-unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-factory-help(a)opensuse.org
Hi,
on popular request, we separated the debuginfo packages from Factory into a
separated repository.
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.
bye
adrian
--
Adrian Schroeter
SUSE Linux Products GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany
email: adrian(a)suse.de
---------------------------------------------------------------------
To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-factory+help(a)opensuse.org
I just found a little annoying thing in Postfix 2.3.2 from factory..
There's a missing definition in the SPEC that disables cyrus sasl
authentication.
I simply added export CCARGS="$CCARGS -DUSE_CYRUS_SASL" to the %build
block, and everything worked fine.
Oh, 10.2 isn't yet defined in Bugzilla, so I didn't post anything in
there about this.
--
Anders Norrbring
Norrbring Consulting
---------------------------------------------------------------------
To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-factory+help(a)opensuse.org
Andreas Jaeger wrote:
> I only made a minimal list of patterns - and now want to open a new
> discussion on what kind of patterns we should have.
> I can add everything I find usefull - but please tell me what you find
> usefull ;-)
Without having thought a lot about it - the initial selection by
patterns/groupings is meant to give the user a system with a set
software suitable for the primary purpose(s) of the machine being
installed.
So what are the typical main roles of an openSUSE system?
Desktop
|
+--- Desktop for/with multimedia
+--- Desktop for development
+--- Desktop for office/backoffice
+--- etcetera
|
Laptop
+--- (not sure how to divide this)
|
Server
|
+--- Fileserver
+--- Internetserver (DNS, web etc.)
+--- Database
+--- Directory
+--- Firewall, network server
+--- etcetera
|
[other roles?]
This is only a proposal - I really just wrote it up in five minutes.
Maybe it's entirely in appropriate.
Maybe the selection is 1-2-3 step: Primary qualifier, secondary
qualifier, plus add-ons (things you might want to do regardless of
which type of system): "Experienced User", "Kernel development", ....
Primary and secondary qualifier could fit into one page/window in a
tree-style display as the above, and going to the 2nd window for
add-ons could be made optional, such that new-bies or non-techies would
have a fast-path, whereas techies and/or experienced users would still
have the option of a detailed selection etc.
/Per Jessen, Zürich
>>>> Matthias Koenig <mkoenig(a)suse.de> 08/28/06 1:38 PM >>>
>Andreas Jaeger <aj(a)suse.de> writes:
>
>> Jasem Mutlaq <mutlaqja(a)ikarustech.com> writes:
>>
>>> Hello,
>>>
>>> Sorry if this is not the appropiate list to discuss
>>> this issue.
>>>
>>> Santa Barbara SBIG CCD camera is one of the most
>>> popular cameras used in astronomy. In order to
>>> operate, the CCD requires a firmware to be uploaded
>>> upon detection on the USB port. Otherwise, you can't
>>> establish any further communications at all.
>>
>> What is the license of this firmware? Is it possible to
re-distribute
>> it? If this is not the case, then we cannot include it,
>
>Unfortunately the Linux Developer Kit from SBIG does not contain
>any hint about the license of the firmware. Though the included
>example code is mentioned to be "free".
>Note, that the camera needs a USB driver, which is provided by SBIG
>as a binary only non-kernel driver also without any license.
I think the best thing in this case is to get in touch with the vendor
and ask for an explicit permission to redistribute the drivers / and
firmware within our openSUSE bundle.
For sure there IS any sort of license bound to their source code.
---------------------------------------------------------------------
To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-factory+help(a)opensuse.org
... because the reply-to on a discussion list is not pointing to the
list....
----- Forwarded message from Joerg Mayer <jmayer(a)loplof.de> -----
Date: Fri, 25 Aug 2006 09:58:47 +0200
From: Joerg Mayer <jmayer(a)loplof.de>
To: Marcel Hilzinger <mhilzinger(a)linuxnewmedia.de>
Subject: Re: [opensuse-factory] Announcing Yast-GTK
In-Reply-To: <200608231123.02818.mhilzinger(a)linuxnewmedia.de>
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 <jmayer(a)loplof.de>
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 <jmayer(a)loplof.de>
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: opensuse-factory+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-factory+help(a)opensuse.org
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, aj(a)suse.de, 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
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: opensuse-factory+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-factory+help(a)opensuse.org