- openSUSE Project

[opensuse-project] Nordic irc-channel
by Martin Schlander 10 Jul '08

10 Jul '08

I'm just writing to inform that a common nordic irc-channel has been created. #opensuse-nordic on the freenode irc-network. The official languages of the channel are Swedish, Danish and Norwegian. People from Finland, Iceland, Faroe Isles, Greenland, Schleswig-Holstein or other places, who read/write these languages are of course more than welcome to join also. --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-project+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-project+help(a)opensuse.org

1 0

[opensuse-project] Re: [Lf_desktop] LSB Package API
by Denis Washington 07 Jul '08

07 Jul '08

On Mon, 2008-06-23 at 15:14 +0100, Scott James Remnant wrote: > My general feeling, having spoken to lots of ISVs, is that they don't > actually _want_ this. > > In order to support their customers, they're well aware that they have > to target particular distributions and versions - and they're quite > happy working and certifying particular vendors individually. I'm not in the position of having the chance to speak with ISVs myself unfortunately. I only relied on what seemed to have been communicated on the LSB face-to-face meeting. It might be good if we had more application vendors (and also open-source project maintainers) speaking up on this issue in the general or the particular proposal. Regards, Denis --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-project+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-project+help(a)opensuse.org

1 0

[opensuse-project] debayan wants to keep up with you on Twitter
by debayan 03 Jul '08

03 Jul '08

To find out more about Twitter, visit the link below: http://twitter.com/i/d3174c254cebbc9da27d667d63e64a89be38e846 Thanks, -The Twitter Team About Twitter Twitter is a unique approach to communication and networking based on the simple concept of status. What are you doing? What are your friends doing—right now? With Twitter, you may answer this question over SMS, IM, or the Web and the responses are shared between contacts. This message was sent by a Twitter user who entered your email address. If you'd prefer not to receive emails when other people invite you to Twitter, click here: http://twitter.com/i/optout/6a710413b71c46dbc468764c1748607ed0926a54 --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-project+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-project+help(a)opensuse.org

1 0

[opensuse-project] openSUSE GNOME meeting (2008/07/03)
by Rodrigo Moya 03 Jul '08

03 Jul '08

* 11 is out, 11.1 roadmap posted, with much shorter development cycle * User issues review: - 'Failed to contact repository' and others after some updates with gnome-packagekit - Package download errors 1st try, retry always works (zypper) - PulseAudio and other sound systems incompatibilities is the most common problem * Helping Hands update: - Big success last week (73 people on the channel), newcomers now regulars to this channel as a result - Next Friday, targeted presentations, openOffice with thorsten and radek - Following Evolution, with the Evo team - A general session will happen once a month AI: suseROCKs to find time for regular montly session * 11.0 updates: - Remember to tag with gnome-update - Nautilus and firefox updates posted, yast2-gtk and packagekit in the queue - PulseAudio updates soon to be posted - Test updates at http://download.opensuse.org/update/11.0-test * Time shift meeting: - We don't have a clear time for the time shift meeting, so people have missed them sometimes - Will follow project meeting time shifts AI: jpr to relay to CJP the canonical time shift time * Benchmark/Performance testing: - Keep up-to-date performance/profiling pages on the wiki - Scripts to be packaged for 11.1 AI: casualprogrammer/suseRocks/hobbsc to discuss performance testing with federico * 11.1 features: - http://en.opensuse.org/GNOME/Ideas/11.1 - Deadline extended to July 7th - Meeting after GUADEC will be used to assign work from the ideas AI: everyone to blog about it to get more ideas submitted (from planet gnome and other planets) * 2.23 update: - All done except for bindings - Stuff is starting to appear on FACTORY * PulseAudio update: - PA switch for the whole distro for 11.1 a possibility - glitchfree branch packages ready next week * Agenda for upcoming meeting: - Next week no meeting because of GUADEC -- 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

1 0

[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 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

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 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

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 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

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 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

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 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

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 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

1 0