June 2008

[opensuse-project] openSUSE GNOME meeting (2008/06/26)
by Rodrigo Moya 26 Jun '08

26 Jun '08

* 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 … [View More]

1 0

[opensuse-project] Build Service downtime 2nd July
by Adrian Schröter 25 Jun '08

25 Jun '08

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 … [View More]

1 0

[opensuse-project] Re: [opensuse] Protecting the openSUSE Project from "poisonous people"
by Andreas Jaeger 25 Jun '08

25 Jun '08

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 … [View More]

1 0

[opensuse-project] Re: LSB Package API
by Denis Washington 24 Jun '08

24 Jun '08

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 … [View More]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 [View Less]

1 0

[opensuse-project] Protecting the openSUSE Project from "poisonous people"
by Andreas Jaeger 23 Jun '08

23 Jun '08

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 … [View More]

1 0

[opensuse-project] Re: LSB Package API
by Denis Washington 22 Jun '08

22 Jun '08

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 … [View More]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 [View Less]

1 0

[opensuse-project] LSB Package API
by Denis Washington 22 Jun '08

22 Jun '08

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 … [View More]

2 1

[opensuse-project] Re: [packaging] LSB Package API
by Denis Washington 21 Jun '08

21 Jun '08

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 > &… [View More]

1 0

[opensuse-project] Restricted Formats: freetype2 with subpixel hinting
by Rafał Miłecki 21 Jun '08

21 Jun '08

Hi, I've created my first .ymp file which is supposed to install freetype2 package with subpixel hinting enabled (M17N repository). Can you review if this file is correct and if so, put this on http://opensuse-community.org/ and link on pages: http://opensuse-community.org/Restricted_Formats/11.0 http://opensuse-community.org/Restricted_Formats/10.3 This file should work fine with 10.3 and 11.0. -- Rafał Miłecki

1 0

[opensuse-project] Re: LSB Package API
by Denis Washington 21 Jun '08

21 Jun '08

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 … [View More]

1 0

Main

Development

Information

Community

Social Media

Other

openSUSE Project