* 11.1 features
+ GNOME 2.23.x mostly submitted to Factory
+ 2.24.1 will be for 11.1
+ Better multihead support (more automatic / less manual, less buggy)
+ Lots of PulseAudio complains in #suse, need a wiki page for PulseAudio
common problems and solutions
+ 11.1 ideas should be announced more widely
AI: rodrigo to write PulseAudio wiki page
AI: suseROCKS to spread the word about 11.1 ideas page
AI: rodrigo to forward suseROCKS announcement mail to opensuse(a)opensuse.org
* Helping Hands
+ 1st presentation tomorrow (14:30 UTC)
+ Next 3 will be evolution, openoffice and multiscreen
+ Helping Hands will cover all sections of openSUSE, not only GNOME
* Multiscreen
+ Nothing is changed yet from what we have in 11.0
+ Code has been merged into GNOME 2.23 mainline
+ Many things missing still:
- many problems in X drivers, hard to fix
- missing functionality in g-s-d and g-c-c
- app bugs (https://bugzilla.novell.com/show_bug.cgi?id=374148)
* Agenda for next meeting
+ Benchmark/Performance testing
+ Issues users are having with latest 11.0
+ AI: everyone should troll through a few channels and mailing lists and
come up with issues users are having
--
Rodrigo Moya <rodrigo(a)novell.com>
---------------------------------------------------------------------
To unsubscribe, e-mail: opensuse-project+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-project+help(a)opensuse.org
As announced earlier, we will do our maintenance day on
Wednesday next week, the 2nd July
A server room will get an upgrade and at the same time we may upgrade
also our backend server. This might take the whole day and maybe even some
hours on thursday.
This will affect all package building, the access to build status and sources
and also the package search behind http://software.opensuse.org/search.
The current state of our backend server is that it is very loaded, the
filesystem is nearly full which makes the system also slow.
Please do NOT create large new repositories atm, we would need to remove them
to keep the service running.
thank you for your patience.
adrian
--
Adrian Schroeter
SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg)
email: adrian(a)suse.de
---------------------------------------------------------------------
To unsubscribe, e-mail: opensuse-project+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-project+help(a)opensuse.org
Clayton <smaug42(a)gmail.com> writes:
> I attended a conference in California last year and Josh Berkus was a
> presenter. He talked for an hour on this very subject.... his
> presentation is here:
>
> http://www.powerpostgresql.com/download/TFCKUpload/25.pdf
I'm aware of the google presentation:
http://www.slideshare.net/oscon2007/os-fitzpatrick-sussman
Where they say that at one point you need to make a stand against them.
Thanks for that link.
>
> He makes a clear point about "Poisonous People" that all open source
> communities should pay attention to.... To effectively _destroy_ your
> community.... quoting....
> =======
> Maximize the damage they can do!
> 1. Argue with them at length
> 2. Denounce them venomously
> 3. Ban them
> 4. Argue with them in other projects
> 5. Allow them back into your project
> 6. GOTO 1
> =======
> It seems that we as the openSUSE community are following these steps
> exactly. That is _not_ a good thing.
We're at number 3 and did not allow him back in the project. He come
back under disguise - took a shortcute ;-)
Read again what I wrote:
In the meantime, we would like to remind others on the mailing lists
to stop responding to his emails.
I agree, we have to stop at number 1 and discourage him instead of
encouraging.
> Something to think about. Do we take steps to eliminate dissenting
> opinions? Or do we allow it? Do we label someone as poisonous to the
> community and ban them? What if the point they are making, although
> maybe poorly stated, is a valid one?
We're not speaking about his points about KDE4, we're speaking about his
violation of our rules in the past.
> This is a critical point in this community's evolution... and whatever
> action that is taken, it MUST be taken with full knowledge of the long
> term effects.
Let's followup on the project mailing list, reply-to is set,
Andreas
--
Andreas Jaeger, Director Platform / openSUSE, aj(a)suse.de
SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg)
Maxfeldstr. 5, 90409 Nürnberg, Germany
GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126
On Tue, 2008-06-24 at 12:03 +0100, Richard Hughes wrote:
> On Sun, 2008-06-22 at 20:02 +0200, Denis Washington wrote:
> > We shouldn't resignate just because nothing came out of the previous
> > attempts. Also, the LSB Package API is designed to require as little
> > adjustments as possible to installers - it's just to calls and a single
> > file, after all.
>
> Uses a DBUS service: check
> Uses pluggable backends: check
> Use PolicyKit: check
> Use an XML parser: check
> System activation: check
> Define own linked list implementation: check
I don't know where you a heading. The D-Bus service, pluggable backends,
the XML parser, and system activation are all things that installers
don't have to deal with. They just use the few functions from
liblsb_package.
> > As already mentioned before in this thread, the focus of PackageKit and the
> > LSB Package API are quite different, so there is no big reason for them to
> > not exist side-by-side.
>
> Err, http://www.linuxfoundation.org/en/LSB_Package_API suggests
> otherwise.
>
> You've got calls to PolicyKit, a system activated daemon, pluggable
> backends - you might as well call the project LSBPackageKit. You don't
> appear to have any defined scope for the project and it seems to be just
> be technology-bingo at the moment.
Just because it does use the same technologies, that doesn't mean the
APIs' scope is the same. You should know enough about your project to
realize that the LSB Package API is focused on entirely different needs
(providing an interface for third-party app installers) than PackageKit
(provide an API for the packaging system, based on distro repositories).
> > I don't think this is a corner case at all. For one thing, propietary
> > applications might just don't play a role _because_ there is no really
> > good distribution method for them - the typical chicken-and-egg problem.
> > (I'm not saying this is the only reason, but an important one.) We're
> > just not giving them an easy method of cross-distro integration. I think
> > providing this is important.
>
> Have you talked to customers? I have. Lots of them. Customers don't want
> DBUS services or PolicyKit, they want one of two things:
>
> 1. A tested (supported) binary package for something like RHEL and SLED.
> 2. An installer that uses something like /bin/sh for the other distros.
Again, ISVs don't have to deal with D-BUS etc. Those are _implementation
details_. They can just use a simple C API which could also be easily
wrapped into simple command-line tools.
> If you want them to use a library to install stuff, you better make it
> static (else they have to depend on really new versions of distros) and
> also make it very lightweight, libc type stuff. Most of this closed
> source stuff has to install on distros 5 years old, and continue to work
> on distros 2 years in the future.
The LSB Package API would only be in newer versions of the LSB, so
support of legacy distros is not that high on the list. (On any older
distro, no one could rely on the API even being there.)
> > Second, this way of distribution will help open-source projects as well.
> > It would make it really easy for them to distribute bleeding-edge
> > versions of there apps that integrate well into the packaging system
> > without having to package for each and every package manager.
>
> Talk to the distro maintainers. They really don't want random projects
> replacing supported packages. Packages are not normally just the
> upstream tarball with a spec file - normally the packager includes spec
> files to make the package compile, or integrate well with the distro.
> Then there's the world of pain that comes from security errata.
No packages are going to be replaced. LSB applications are required to
install to /opt, so nothing is overridden. Even the package naming won't
clash (it's "lsb-<provider>-<package name>" in the implemented RPM and
DPKG backends).
> I really think you should talk to distro maintainers as well as closed
> source vendors before coming up with any more API.
A number of ISVs have already been talked to; see the comments from Jeff
Licquia.
Regards,
Denis
---------------------------------------------------------------------
To unsubscribe, e-mail: opensuse-project+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-project+help(a)opensuse.org
While the vast majority of participants on the openSUSE mailing lists
are good citizens of those lists, we have from time to time had
problems with a few individuals who seek to use the lists to derail
conversations and abuse other members of the project.
Last October, we banned a user going by the name of Aaron Kulkis from
the lists. He has rejoined the mailing lists under several new
identities, (including "Matt Archer," "Raskolnivkov Tkachuk," "Evans
Garde," and "Washington Irving").
This has been brought to the board's attention, and we are
investigating options to enforce the decision we made last October.
In the meantime, we would like to remind others on the mailing lists
to stop responding to his emails. If you see him using another alias,
just send a note to opensuse+owner(a)opensuse.org.
Thanks,
Andreas Jaeger
Chairman openSUSE Board
--
Andreas Jaeger, Director Platform / openSUSE, aj(a)suse.de
SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg)
Maxfeldstr. 5, 90409 Nürnberg, Germany
GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126
On Sun, 2008-06-22 at 14:15 +0100, Richard Hughes wrote:
> On Sat, 2008-06-21 at 11:51 +0200, Denis Washington wrote:
> > Some time ago, it was discussed on an LSB face-to-face meeting that an
> > API should be developed that allows ISVs to install sotware packages
> > which integrate into the package manager - the "Berlin Packaging API".
> > While the idea seemed to be well received, there didn't seem much
> > progress since then, except for a wiki page with a rundimentary proposal
> > [1]. Considering that third-party software installation is an undeniably
> > important weak spot of the Linux infrastructure, I found this was a
> > shame.
>
> Sure, it's been tried before a few times before and fallen on it's face
> each time. There's a reason that PackageKit uses the distro supplied
> packages, rather than trying to spin it's own thing.
We shouldn't resignate just because nothing came out of the previous
attempts. Also, the LSB Package API is designed to require as little
adjustments as possible to installers - it's just to calls and a single
file, after all.
> > To reignite the the initiative, I decided to design and develop a
> > prototype implementation of the Berlin API, most creatively named the
> > "LSB Package API". It is designed as a simple D-Bus interface
> > accompanied with an XML-based package description format. A detailed
> > description and the source code can be found on this page:
> >
> > http://www.linuxfoundation.org/en/LSB_Package_API
>
> Sounds quite like PackageKit, which has been developed for the last year
> or so with buy-in from most of the big distros. PackageKit doesn't try
> to replace the entire stack, only make some sort of abstraction for GUI
> tools where such an abstraction makes sense.
>
As already mentioned before in this thread, the focus of PackageKit and the
LSB Package API are quite different, so there is no big reason for them to
not exist side-by-side.
> Being blunt, no distro is going to support a LSB package API. To me, a
> distro is basically:
>
> community+trust+infrastructure
>
> If you take away the trust (letting other people create and sign
> packages), the infrastructure (letting other people host packages and
> manage security errata) and the community (basically reduced to PR)
> you've got nothing left.
>
> The cost of a distro rolling it's own packages is trivial considering
> the advantages of the vendor trust model, with a single infrastructure
> and support.
The distro model is nice (and arguably better than the LSB Package API)
if the packages you like to have are in the repos in sufficiently new
versions. But if you need to go past that (bleeding edge versions, not
widely spread apps), things get more difficult currently. Especially
propietary applications just cannot be distributed by the distros
directly.
> > The implementation currently supports integration into RPM and dpkg; due
> > to its modular nature, support for more package managers could be added
> > later on.
>
> Looks like you've not considered localisation, multi-lib, multiple
> versions of packages, or any of the problems solved with solutions like
> NEVRAs. I would suggest to read the rpm(+yum), dpkg and conary sources
> before you even start to propose APIs.
Naturally some things are not considered yet. That's why I called the
spec and implementation I released a "starting point", not the
completely finished thing ready for production. There are quite a few
points that will have to be thought through and added, but I don't think
it's impossible to do so on top of the current basic design.
> > I hope this implementation will act as a starting point for resurrecting
> > the Berlin API process. Let us overcome the "Third-party software
> > installation on Linux sucks" problem and strive to a brave new world of
> > easily distributable Linux software! ;)
>
> I think you are looking for a solution to a problem that doesn't exist.
> For the corner cases of where this does apply (proprietary software)
> this is not enough of a use case to justify all the work required.
I don't think this is a corner case at all. For one thing, propietary
applications might just don't play a role _because_ there is no really
good distribution method for them - the typical chicken-and-egg problem.
(I'm not saying this is the only reason, but an important one.) We're
just not giving them an easy method of cross-distro integration. I think
providing this is important.
Second, this way of distribution will help open-source projects as well.
It would make it really easy for them to distribute bleeding-edge
versions of there apps that integrate well into the packaging system
without having to package for each and every package manager. It will
also help those projects which are not widely used enough to be in
distro repos, as they can more easily release binary distributions
without having to depend on getting packaged by the distros. I really
believe this decentralism would be very nice to have, especially in
something as naturally decentralized as the open source community.
Regards,
Denis
---------------------------------------------------------------------
To unsubscribe, e-mail: opensuse-project+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-project+help(a)opensuse.org
Hi,
Some time ago, it was discussed on an LSB face-to-face meeting that an
API should be developed that allows ISVs to install sotware packages
which integrate into the package manager - the "Berlin Packaging API".
While the idea seemed to be well received, there didn't seem much
progress since then, except for a wiki page with a rundimentary proposal
[1]. Considering that third-party software installation is an undeniably
important weak spot of the Linux infrastructure, I found this was a
shame.
To reignite the the initiative, I decided to design and develop a
prototype implementation of the Berlin API, most creatively named the
"LSB Package API". It is designed as a simple D-Bus interface
accompanied with an XML-based package description format. A detailed
description and the source code can be found on this page:
http://www.linuxfoundation.org/en/LSB_Package_API
The implementation currently supports integration into RPM and dpkg; due
to its modular nature, support for more package managers could be added
later on.
I hope this implementation will act as a starting point for resurrecting
the Berlin API process. Let us overcome the "Third-party software
installation on Linux sucks" problem and strive to a brave new world of
easily distributable Linux software! ;)
Best regards,
Denis Washington
[1] http://www.linuxfoundation.org/en/Berlin_Packaging_API
---------------------------------------------------------------------
To unsubscribe, e-mail: opensuse-project+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-project+help(a)opensuse.org
On Sat, 2008-06-21 at 06:59 -0700, Dan Kegel wrote:
> On Sat, Jun 21, 2008 at 1:32 AM, Denis Washington <dwashington(a)gmx.net> wrote:
> > Some time ago, it was discussed on an LSB face-to-face meeting that an
> > API should be developed that allows ISVs to install sotware packages
> > which integrate into the package manager - the "Berlin Packaging API".
> > While the idea seemed to be well received, there didn't seem much
> > progress since then
>
> I dislike that route intensely. Why, I'm not sure. Perhaps
> because it encourages ISVs to manage package updates themselves,
> perhaps because it smacks of the complexity of Microsoft's MSI.
>
> I'm more interested in the single-click install idea Suse's
> working on, since it's much less of an end run around
> normal Linux packaging practices. And I have a summer intern
> to throw at the problem, so perhaps I'll make some headway on
> it.
The problem I currently see with single-click install is that it still
relies on a single package format (.rpm), so there would have to be
several packages of the same application again. Another particular
problem I see is security: RPM runs as root, so post-install routines
will do so too. That's why I tried to do an architecture that works
without root privileges (in many cases at least). But maybe there are
are already plans how to address this? I must admit I'm not all that
well-informed about SuSE's one-click install.
> Can we move followups to packaging(a)lists.linux-foundation.org rather
> than cc'ing all those lists?
OK. I wanted to get as many parties as possible on board, but now let's
say: whoever likes to follow this discussion is encouraged to to join
packaging(a)lists.linux-foundation.org [1]. Follow-ups should only be sent
there.
Regards,
Denis
[1] https://lists.linux-foundation.org/mailman/listinfo/packaging
---------------------------------------------------------------------
To unsubscribe, e-mail: opensuse-project+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-project+help(a)opensuse.org
On Sat, 2008-06-21 at 13:20 +0200, Yaakov Nemoy wrote:
> How is this different than PackageKit? PackageKit seems to cover the
> use case of presenting a comprehensive API and userspace tools to
> manage packages consistently across distros. What can the Berlin API
> do that PackageKit doesn't do, and doesn't make sense for PackageKit
> to do?
>
> -Yaakov
While the use cases of PackageKit are related to the Berlin API, they
are pretty different. PackageKit is focused on providing a frontend for
managing repository-based package systems, like apt and and yum. It is
mainly thought to abstract installation and upgrades from package
repositories, like when an application likes to install a package with a
particular name from the distro's repos. However, it does not address
the problem of software distribution itself - the repositories and
package files are still specific to the packagaing system.
The Berlin API, on the other side, does exlclusively deal with providing
a package-manager-neutral software distribution method. So the Berlin
API is not a replacement for PackageKit, but a complement. In fact, as
the software installed with the Berlin API is added to the package
system's database, it can be managed (e.g. uninstalled) with PackageKit
afterwards - a dream team! ;)
Regards,
Denis Washington
---------------------------------------------------------------------
To unsubscribe, e-mail: opensuse-project+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-project+help(a)opensuse.org