June 2012 - openSUSE Factory - openSUSE Mailing Lists

[opensuse-factory] EOG issue in 12.1 Tumbleweed
by Carl Fletcher 25 Jun '12

25 Jun '12

Eye of Gnome fails to start. Issue eog in a terminal, results in (eog:5956): GLib-GIO-CRITICAL **: Timeout was reached rpm -qi eog Name : eog Version : 3.2.2 Release : 2.4 Architecture: x86_64 Install Date: Sat 23 Jun 2012 04:47:17 BST Group : Productivity/Graphics/Viewers Size : 1965107 License : GPLv2+ ; LGPLv2.1+ Signature : DSA/SHA1, Thu 21 Jun 2012 23:13:42 BST, Key ID 01a7de5aa840f92c Source RPM : eog-3.2.2-2.4.src.rpm Build Date : Thu 21 Jun 2012 23:11:57 BST Build Host : build24 Relocations : (not relocatable) Vendor : obs://build.opensuse.org/openSUSE:Tumbleweed URL : http://www.gnome.org/ Summary : Image Viewer for GNOME -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

2 2

[opensuse-factory] Motivation of community maintainers(Was: Calling for a new development model by coolo)
by Marguerite Su 25 Jun '12

25 Jun '12

Hi, all, I don't know much on the infrastructure thing like being talked in the original topic. I did notice some projects of our current development model didn't response well. According to coolo, some factory packages didn't got fixed in two weeks or more, even if we have email notification and a factory repository enabled in all devel projects. It means if you login b.o.o every day, you must be able to notice that your package fails. But some projects of our current development model responses very well. (like auto-build team) Those two apparently different situations both happened under the same development model. So personally I think it's not because we have faults or bias on the design part of current development model. So why everyone of us are so _hurry_ to design a new model for one of our major release? It requires many collaborations. For instance, if we want to raise the priority of Tumbleweed, we have to adjust a lot of things like OBS, tumbleweed team and almost every other teams' focuses. I think it's foreseeable that we won't finish it in a short time. Especially we are under such a tough situation that many repository maintainers are not available right now. (everyone knows they are absent, but no one knows where they are absent for/to.) They can't be awaken under a very short time like two or three months. So I think the temporary solution to 12.2 is that we existing active maintainers have to contribute more. Instead of blaming and marking invalid or "won't fix", we have to fix every bug we met and are able to fix. Actually personally I think it's not because current development model are not "good", but we lack of a supervisor system to push it to be good. We didn't educate our maintainers so well to let them know their responsibilities. (eg: they have to test the package in his maintaining repository for stability, to make them build for factory, to answer bug reports, instead of just accept and forward. Because they have super permissions than ordinary packagers, they have to take the related responsibilities) Every existed and to-be-designed development model is based on one simple hypothesis, that is, every( or most of, majority of) maintainer is active, especially repository maintainers. But it's not the case right now. we have almost 30000 packagers on b.o.o, but anyone ever calculate the active ratio? It must be very regretful. Imagine now we have 30000 email senders to this mailing list, it must be a huge traffic. but it's not the case right now. I guess we have an active ratio even lower than packman. (they have only 100+ maintainers, but their mailing list is as busy as ours) So now the case is: we are not lacking of maintainers and bug fixers, but lacking of active ones. you know, we're a big FOSS empire as big as Debian! So personally I think what we need to do is find a way to wake up our sleeping maintainers and packagers, instead of designing a new development model or something ASAP. (personally I think coolo mistakes one thing: it's not because we have too many maintainers so the current development model can't fulfill the needs, but we lack of enough active maintainers to make our engine running! the OBS traffic and infrastructure pressure mostly comes from those who builds but not builds for factory.) If there's anyone doesn't believe it, let's make a test(or ping, which is famous in accent Chinese kingdom, to hand out a report to every majors in his empire, and ask them to reply.), create a new account, to require "add role" permission from every devel project, then coolo will know which ones are active and which ones are silent. To solve this problem, personally I have a few ideas: 1. We have to kindly warn those silent repository and package maintainers two or three times, then do a clean. 2. Then we have promote some active packagers who are not maintainers yet. 3. Do it regularly. 4. we have to enable build failure notifications of devel repository/factory on hermes.o.o by default, and it can't be shutdown by yourself. you can mark it spam, but you can't shut it down. (I am the maintainer of M17N, and we have 3 sub projects and 320 packages. many of the package maintainers are promoted in 2007 or even earlier, I might be wrong about it, since I am fresh and don't know when we have OBS. but they didn't submit any single SR since then. many of them are even SuSE staff. they may even work for Windows now, girl! what if they didn't maintain their packages? oh others don't even know what his package is for.) 5. We need a check-in system. Not every package needs to be modified regularly. But we have to have the information that how many maintainers we still have. 6. We need a karma system. At first I want to be clear, everyone is born equal, but hard workers need to be encouraged. And a ranking system is not against our guiding principle, because we already have ranking systems like members and the board. But we're lacking of a quantified one. Nowadays if once you're an repository maintainer, you're still repository maintainer when you're died. We kept adding new ones, but then maintainers can shirk, "oh he will update that package". If everyone thinks so, then no one will update that package or fix that bug. Of course those karma doesn't mean anything, because no one here is payed to work except SuSE people. (But they do the works far beyond their salaries.) = For packagers: = Those karma can "exchange" build power on OBS. Today our OBS can build most of the packages in a short time (if OBS is not broken). But what if you're working on an important package? buy it. Those karma can "exchange" openSUSE member position. Today we're using manual selection, which requires a lot of work so reacts slow. And some losers might be question it. A quantified high karma which can't be earned in one or two years solves that problem. Those karma can "exchange" openSUSE gifts, like our lizard doll. Actually I was so active because last Xmas SuSE China sent me a lizard doll and a novell cup, I want a larger one this year. Gifts will be very valuable to newbies. If you have 30000 karma, why not deliver you a real lizard? XD. = For repositories: = The devel repositories' karma equals to the sum of their maintainers plus an adjustable amount from coolo, according to their recent busy hours and importance to our factory. Then no one will carelessly add those who will be certainly silent after a while.( because one's karma can be negative!) = How to earn karma? = By creating packages which are not in factory yet, by adopting existing unmaintained packages(no package will be dropped sadly), by developing features on f.o.o, by fix bugs on b.n.c, by answering question on mailing lists...... ( a high karma person's answer might be more useful. after we have a karma system, I personally no longer need to get the first impression by name or email address, it's pure guess who to trust nowadays, you know, to a fresh woman and a so called foreigner like me, every foreign nickname looks the same to me) Things like that, and by check-in every day (a check-in means 1 point. And since you're on b.o.o every day, why not fix some minor bugs?). If you're not active, those karma will fade. drop 1 point per day. or you didn't claim to fix your bug, it will drop some amount. If you got a negative karma, you have to work a lot to make it positive. after you got a certain negative number of karma like -30, sorry, you build power is limited. like lauchpad, you have to wait certain hours to queue your builds. Some of the karma are forever. like contributing to 12.2 will +3 golden points. it will not fade and is commemorate. But such karma can't let you be in a repository maintainer status forever, because repository maintainership will require 30 points. This karma system is ported from plurk, launchpad, foursquare and many existing social networks. It's been tested for a long time and useful to maintain active ratio. And it can be port to almost everywhere like our connect.o.o, our planet, our forums and more, even to board election( without 100 points? sorry, you can't be a candidate; love coolo? give him 3000 points and buy him a chairman!). Those are just thoughts and personal ideas I think we should have. If interested, we can improve them; if not, it will not weaken the faith I hold on openSUSE. Greetings, Marguerite -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

2 1

[opensuse-factory] Please help with lilypond
by Dave Plater 25 Jun '12

25 Jun '12

Reading another thread on the factory list has prompted this request. I'm currently computerless and am unable to finish lilypond which currently has two problems : 1) It currently requires gnutls-extra for it's build, this is easy to fix and if this stupid phone could download spec (text) files I could have fixed it myself. 2) The documentation part of the build takes far too long. This I started to fix on by putting the doc build in a linked package and not building the "lilypond snippets". This is still WIP. The documentation used to be available as a large separate tarball but I couldn't find it in my last moments at the pc so my plan is to leave it out as the docs are duplicated online at lilypond.org. Dave -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

2 2

[opensuse-factory] The languished meaning of "maintainer" (was: Calling for a new openSUSE development model)
by Jan Engelhardt 25 Jun '12

25 Jun '12

Robert Schweikert wrote in http://lists.opensuse.org/opensuse-factory/2012-06/msg00489.html : > >I believe that an underlying issue to the overall state is the package >maintenance model. Look at any perl or python package in the devel >projects and you'll find tons of people listed as "maintainers" but >almost non of them is a "true" maintainer. Everyone of the listed >"maintainers" is inherited from some parent project and in the end no >one really feels responsible. Indeed - but: it is the way it is represented in the webui that is misleading. If you use the command line client, `osc meta pkg`, you get a *much* more useful and concise set of people - and usually the people who *really are* responsible. If the so-obtained list is empty, you can consider the package abandoned already. >That this is an issue is also evident in the increased mail traffic on >the list about lingering SRs. The problem with lingering SRs has more to do with the "maintainer"-called role being overloaded - *in prj context*. I concur with your observation. 22 "maintainers" in games, 42 in devel:libraries:c_c++ don't paint a good picture. But server:irc's list of 8 also sports the linger problem. There are a handful of prj-level actions: - the true maintainer, IOW, "I maintain indeed all packages in here". This only makes sense for a limited set of develprjs, predominantly those that deal with a single "software stack" (a group of obviously related packages). Examples are network:mail:zarafa, network:telephony:asterisk*. But not games, not d:l:c_c++. - fallback maintainer: responsibility to accept lingering SRs not having been accepted by the bspkg maintainer in a handful of days (3/5/7? maybe settable within the pkgmeta?), provided they meet best judgment. - mentor: responsibility to 1. decline *new* packages - sorting out unsuitable license, ...; 2. approve new packages and perhaps send corrections immediately afterwards, ...; These extra roles are merely for self-description of users, and should simply have the same commit permissions as the current "maintainer" role do now. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

3 4

[opensuse-factory] Calling for a new openSUSE development model
by Stephan Kulow 25 Jun '12

25 Jun '12

Hi, It's time we realize delaying milestones is not a solution. Instead, let's use the delay of 12.2 as a reason to challenge our current development model and look at new ways. Rather than continue to delay milestones, let's re-think how we work. openSUSE has grown. We have many interdependent packages in Factory. The problems are usually not in the packages touched, so the package updates work. What's often missing though is the work to fix the other packages that rely on the updated package. We need to do a better job making sure bugs caused by updates of "random packages" generate a working system. Very fortunately we have an increasing number of contributors that update versions or fix bugs in packages, but lately, the end result has been getting worse, not better. And IMO it's because we can’t keep up in the current model. I don't remember a time during 12.2 development when we had less than 100 "red" packages in Factory. And we have packages that fail for almost five months without anyone picking up a fix. Or packages that have unsubmitted changes in their devel project for six months without anyone caring to submit it (even ignoring newly introduced reminder mails). So I would like to throw in some ideas to discuss (and you are welcome to throw in yours as well - but please try to limit yourself to things you have knowledge about - pretty please): 1. We need to have more people that do the integration work - this partly means fixing build failures and partly debugging and fixing bugs that have unknown origin. Those will get maintainer power of all of factory devel projects, so they can actually work on packages that current maintainers are unable to. 2. We should work way more in pure staging projects and less in develop projects. Having apache in Apache and apache modules in Apache:Modules and ruby and rubygems in different projects may have appeared like a clever plan when set up, but it's a nightmare when it comes to factory development - an apache or ruby update are a pure game of luck. The same of course applies to all libraries - they never can have all their dependencies in one project. But this needs some kind of tooling support - but I'm willing to invest there, so we can more easily pick "green stacks". My goal (a pretty radical change to now) is a no-tolerance strategy about packages breaking other packages. 3. As working more strictly will require more time, I would like to either ditch release schedules all together or release only once a year and then rebase Tumbleweed - as already discussed in the RC1 thread. Let's discuss things very openly - I think we learned enough about where the current model works and where it doesn't so we can develop a new one together. Greetings, Stephan -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

40 173

[opensuse-factory] Live CD/DVD Distro For Japanese
by Kiyomi Kakitsubata 25 Jun '12

25 Jun '12

How can I chenge my project like Live DVD(such as Japanese Localized openSUSE) unofficial to official? In Japan,Ubunts has onofficial Japanese remix distribution,so I want make like this whitch use openSUSE. However,I do not know where could I send e-mail and problem of trademark. What can I do ? Thanks ================================== Kazufumi Watanabe 　kikyo.kakitsubata(a)gmail.com ==2.71828182845904523536028747135== -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

3 3

[opensuse-factory] repository priorities with Tumbleweed
by Thomas Langkamp 23 Jun '12

23 Jun '12

Hi, what is the current suggestion of Greg KH to repository priorities running Tumbleweed? In the early days he suggested flat ones, over time more and more users reported (in forums) that a higher one for Tumbleweed (or even a complicated priority-hierarchy) works better. I ask because I believe that my KDE "ksmserver wont start" error of this morning might be related to this. It appeared after zypper dup this morning (64 bit Intel Core2Quad) and won´t let KDE start. So I gave Tumbleweed a higher priority, but that did not help. Maybe I am doing something wrong? But even if my problem has nothing to do with the priorities, please think about my request: - add info on how to handle priorities on the SDB:Tumbleweed - Or even better: Add an automatism to zypper/yast that automagically sets the "right" priorities, while advanced users are still able to customize it Thanks vor Tumbleweed so far - it is great and I love it :D Thomas -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

7 9

Re: [opensuse-factory] repository priorities with Tumbleweed
by Cristian Morales Vega 23 Jun '12

23 Jun '12

On 22 June 2012 15:42, Thomas Langkamp <langkamp(a)tomblog.de> wrote: >> It's not like settings priorities was a big mystery. > > > If this would be the case, why would you write such a lengthy post about > explaining priorities: > http://forums.opensuse.org/english/get-technical-help-here/how-faq-forums/u… Because forums users don't read man pages. And it's so long because: a) I explain dist-upgrade, not just priorities. b) I adapted the text to the public: I repeat the same thing multiple times in different ways. > You do not say here: do not zypper dup with priorities on tumbleweed > But to me you imply the opposite: use zypper dup + priorities if you like > also with TW. > Now Greg K-H in contrary just again said not to give priorities with TW. I already explained why I think I "know better than Greg does" ;-) -> http://lists.opensuse.org/opensuse-factory/2011-11/msg00942.html In any case if you read http://en.opensuse.org/Portal:Tumbleweed you can see Greg only supports a basic repo configuration. If you use Packman you are already outside Greg recommendations (and the "zypper dup --from Tumbleweed" suggestion is biased towards Tumbleweed, doesn't really help with Packman). > So if you both do not agree each other - how could the common user not be > confused. This is why I asked to give an official statement on > SDB:Tumbleweed after the community reached an agreement on what is best and > then not to bother the user with it, but to let Tumblewee automaticaly > select the best priority. You can't set it automatically because priorities are *relative*. Settings a repository with priority 20 will have a different result if there is another repository with a higher priority or if all the other repos have priority 99. But since you read my post in the forum you already understand priorities, don't you? Please, answer these: - What will happen if you set Tumbleweed with a higher priority than the main repo? - What will happen if you set Tumbleweed with the same priority than the main repo? - What will happen if you set Tumbleweed with a lower priority than the main repo? After reading that post you should know the answers. So just decide what behaviour do you want. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

3 2

RE: [opensuse-factory] Re: Tumbleweed / python-kdebase4
by Will Stephenson 22 Jun '12

22 Jun '12

Calligra Replaces koffice2, will check the rest.

2 1

[opensuse-factory] Tumbleweed / python-kdebase4
by Achim Gratz 22 Jun '12

22 Jun '12

It appears that the latest build in Tumbleweed downgraded python-kdebase4 from 4.8.3-5.1 to 4.8.2-7.1 — of course since everything else is at 4.8.3 this breaks dependencies. Looking at the build log dosn't provide a clue as to why it has downgraded, so could someone else please have a look at what is going on with that package? The source package in the repo is at 4.8.3 like it should. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptation for Waldorf Blofeld V1.15B11: http://Synth.Stromeko.net/Downloads.html#WaldorfSDada -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

5 8