openSUSE Project June 2008

project@lists.opensuse.org

34 participants
26 discussions

openSUSE GNOME meeting (2008/06/26)

by Rodrigo Moya

* 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

12 years, 5 months

Build Service downtime 2nd July

by Adrian Schröter

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

12 years, 5 months

Re: [opensuse] Protecting the openSUSE Project from "poisonous people"

by Andreas Jaeger

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

12 years, 5 months

Re: LSB Package API

by Denis Washington

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

12 years, 5 months

Protecting the openSUSE Project from "poisonous people"

by Andreas Jaeger

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

12 years, 5 months

Re: LSB Package API

by Denis Washington

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

12 years, 5 months

LSB Package API

by Denis Washington

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

12 years, 5 months

Re: [packaging] LSB Package API

by Denis Washington

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

12 years, 5 months

Restricted Formats: freetype2 with subpixel hinting

by Rafał Miłecki

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

12 years, 5 months

Re: LSB Package API

by Denis Washington

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

12 years, 5 months

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openSUSE Project June 2008