June 2012 - openSUSE Project - openSUSE Mailing Lists

[opensuse-project] How we will use the GSoC money
by Vincent Untz 18 Jul '24

18 Jul '24

Hi, (let's see how a public discussion about money goes :-)) The Google Summer of Code brings us great students, but also means that the openSUSE project will get $8000 (if I'm not mistaken) at the end of the summer. That's $500 per student. A while ago, I requested comments on my blog about what to do with the money, but didn't get any feedback. So I take this as "do what you feel is best", and this mail is about the plan. As a reminder, the main issue is that we will likely not have the openSUSE Foundation created in time for this. For instance, Google would like us to get some form filled before the end of June; this is not a mandatory timeline, but I think it shows that we won't be ready with the Foundation for that. The current plan is to give that money to another organization we feel close to, and I have two candidates in mind: - the Software Freedom Conservancy (http://sfconservancy.org/) it's a really nice org that provides a home for various cool projects (see http://sfconservancy.org/members/current/) and those projects help make openSUSE a great project. - the Desktop Summit (https://www.desktopsummit.org/) it's one of the biggest event this year, and this would help us have some more visibility (since we'd be sponsors, I guess). I'm sure they would welcome this to secure their budget. Note that an alternative solution would be to leave the money to Google for a future GSoC or similar program, but I feel it's better to use the money where it can make a difference today. Now, it's not too late to change the plan. If you have a better suggestion, please tell us. There's no need to argue forever about it, just explain why you think it's good. Keep in mind that if we cannot receive the money ourselves, this also means that we cannot use it to buy stuff for openSUSE. Pavol and I will take the final decision since we are the GSoC admins for openSUSE. Thanks, Vincent -- Les gens heureux ne sont pas pressés. -- To unsubscribe, e-mail: opensuse-project+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-project+help(a)opensuse.org

22 38

[opensuse-project] download.opensuse.org IPV6 address breaks updates
by Gerald Pfeifer 15 Nov '13

15 Nov '13

I am seeing this with an openSUSE 12.1 system at home, and also a Factory system at work: % host download.opensuse.org download.opensuse.org has address 195.135.221.134 download.opensuse.org has IPv6 address 2001:67c:2178:8::13 And then, when running zypper patch or zypper up, I see Retrieving: repomd.xml [error] Download (curl) error for 'http://download.opensuse.org/update/12.1/repodata/repomd.xml': Error code: Connection failed Error message: Failed to connect to 2001:67c:2178:8::13: Network is unreachable Alas, my provider nor that network at work support IPv6. Still, my system has IPv6 enabled since roaming around on different networks, IPv6 may be present, or even necessary there. (This does not happen all the time, sometimes if I retry a bit later the system uses IPv4 and everything works.) Now, is this just a setup problem and I should simply and unconditionally disable IPv6? Or are some parts of our update or network stack in need of some adjustments? For the time being, unless this is just me running into this, should we disable IPv6 on download.opensuse.org? Gerald -- Dr. Gerald Pfeifer <gp(a)suse.com> || SUSE || Director Product Management -- To unsubscribe, e-mail: opensuse-project+unsubscribe(a)opensuse.org To contact the owner, email: opensuse-project+owner(a)opensuse.org

12 41

[opensuse-project] Scanny: week report
by Piotr Niełacny 20 Aug '12

20 Aug '12

Hi guys, this is my first report about scanny for #1 week: http://ruby-blog.pl/GSoC/2012/05/28/scanny-week-1/ -- Piotr Niełacny -- To unsubscribe, e-mail: opensuse-project+unsubscribe(a)opensuse.org To contact the owner, email: opensuse-project+owner(a)opensuse.org

2 12

[opensuse-project] UEFI situation
by Chris Jones 07 Aug '12

07 Aug '12

17 55

[opensuse-project] SUSE Studio
by Шевцов С.А. 02 Jul '12

02 Jul '12

Здравствуйте! Скажите, пожалуйста, можно ли продавать, как в http://www.linuxcenter.ru/shop/licence/licences/open_suse_12_1_x86_64_with_… свои произведенные с помощью Suse Studio дистрибутивы (уже два сделал),через ООО или ИП? Если да, то какое соглашение нужно? Спасибо заранее! Сергей Шевцов https://www.facebook.com/sshevts Hello! I work in I.M. Sechenov First Moscow State Medical university of http://eng.mma.ru/ senior researcher. We want to create your distro opensuse-based Suse Studio. Would it be possible then to distribute on behalf of our university this distribution? Would it be possible to sell your distribution specialists in biology, medicine, psychology and pedagogy? Thanks in advance! Sergey -- To unsubscribe, e-mail: opensuse-project+unsubscribe(a)opensuse.org To contact the owner, email: opensuse-project+owner(a)opensuse.org

5 4

[opensuse-project] Booster news
by Jos Poortvliet 28 Jun '12

28 Jun '12

Dear friends, The openSUSE boosters have been going through some changes lately. You probably noticed some people left - one to play with ARM devices, another doesn't paint green anymore and a third has his head in the cloud. Others left for new things internally - all in all, leaving the team quite small. SUSE responded by starting to hire new people and took this opportunity to see where the booster team could do better. So, today, while the team is not at full strength yet, we do have something to announce. First of all, we've got a new team lead. Some of you might know him as the Master of Money at KDE: Agustin Benito Bethencourt. He'll bring some fresh ideas to the team and can help us stay Cool. Second, to bring all openSUSE efforts in SUSE in one place, I will be joining the Boosters team. Not much will change and I'll stay in Berlin for now but I'll be working with them more. So. No big changes anytime soon, but we'd wanted to let you know there's something going on and we hope to be back at full strength in a few months, with fresh ideas, energy and efforts to help openSUSE have fun! Until then - we'll keep chippin' away at the build issues in 12.2 and the other thing we've been doing. love and hugs, The Boosters -- To unsubscribe, e-mail: opensuse-project+unsubscribe(a)opensuse.org To contact the owner, email: opensuse-project+owner(a)opensuse.org

9 9

[opensuse-project] [gsoc] osc2 client - summary of week 5
by Marcus Hüwe 26 Jun '12

26 Jun '12

Hi, here's a small summary of the 5th (coding) week. Last week I spent most of my time with working on the cpio module. Finally I ended up with a complete rewrite of osc's "old" cpio module. The cpio implementation details are taken from the cpio 2.11 package. Currently only the "new ascii" format is supported and we can only handle regular files (this is sufficient for our needs). Here's a small example how to use it: # cpio_open is just a convenience method for CpioArchive(filename=fname) with cpio_open(fname) as archive: for archive_file in archive: # print filename print archive_file.hdr.name # print contents print archive_file.read() It's also possible to pass a file-like object to a CpioArchive instance (in this case we do not need to use the with statement). Also it can be "easily" enhanced to support different cpio formats (one just have to write the specific ArchiveReader and ArchiveWriter classes:) ). The code is available at [1] and the testcases at [2]. Todo for this week: * finish the build module * start with working on the package fetching code Marcus [1] https://github.com/openSUSE/osc2/blob/master/osc/util/cpio.py [2] https://github.com/openSUSE/osc2/blob/master/test/util/test_cpio.py -- To unsubscribe, e-mail: opensuse-project+unsubscribe(a)opensuse.org To contact the owner, email: opensuse-project+owner(a)opensuse.org

1 0

[opensuse-project] [reminder] openSUSE Project Meeting tomorrow at 20:00 UTC
by openSUSE Meeting Reminder 26 Jun '12

26 Jun '12

Hello all, The biweekly project meeting will be held tomorrow at 20:00 UTC in #opensuse-project on freenode. Everybody is invited to join and participate! Find out what time the meeting will be in your timezone: http://timeanddate.com/worldclock/fixedtime.html?day=27&month=6&year=2012&h… Agenda of the meeting: http://en.opensuse.org/openSUSE:Project_meeting#Agenda_for_the_next_meeting If you cannot participate and want a specific question to be answered during the meeting, please add your question to: http://en.opensuse.org/openSUSE:Project_meeting#Questions_Section Minutes and logs of previous meetings can be found at: http://community.opensuse.org/meetings/opensuse-project/ Thanks, -- openSUSE Meeting Reminder -- To unsubscribe, e-mail: opensuse-project+unsubscribe(a)opensuse.org To contact the owner, email: opensuse-project+owner(a)opensuse.org

1 0

[opensuse-project] AppStream / Software-Center GSoC project #4
by Matthias Klumpp 25 Jun '12

25 Jun '12

Hi! Some more information about what I'm doing at time to make the Software-Center cross-distro and usable with PackageKit. At time I am in a pretty intense exam phase, so there are a little less changes happening - more will be done after my biggest two exams on 5th July are over. Of course working hasn't stopped. Here's a short summary (I'll tell some things again for better understanding) The key element to get a working Software Center is PackageKit. When I started the project, SC was incredibly slow. After some modifications, it is now usable, which means that it will run with acceptable speed. However, it is still much slower than it's native aptd version. The current design of PackageKit allows only sequential processing of transactions, meaning if one transaction (InstallPackages()) is running, you can't run another one in parallel (GetDetails()). This results in that odd case that users will not be able to browse the software catalog while software is installed. To solve that issue, I introduced the package cache, a SQLite cache of all installed packages and their details. This worked well, but also had all issues of a cache and was not very elegant and generally disliked by many people, including me. So we looked for other solutions and decided to implement "parallel transactions" after a longer discussion. "Parallel transactions" means that you will be able to run some transactions, e.g. everything which reads the cache, in parallel to others, for example one which installs packages. This will enable us to not only show package details while installing stuff, but also to fire many read transactions at the same time at get them processed without delay. The final speed of PK will - of course - depend on how well the backend is written. Downside of this solution is that all backends have to be threadsafe (or created processes and do IPC) and that this feature is non-trivial to implement. Richard Hughes (PackageKit maintainer) and I drafted the specifications of parallel transactions, including some test-cases. Essential for planning the implementation was that a running transactions may never ever block existing ones. (Avoiding situations like everything is waiting to release locks) After planning, implementation started, where we now completely broke backend API. First idea way to create one PkBackend instance per PkTransaction, but after we did many parts of the implementation and I had a working prototype already, Richard stated that initializing one new backend per transaction is a bad idea and a big overhead. Another problem which I had discussed with Daniel (aptcc backend maintainer) before was that with this approach backends can't share cache resources, as they don't have control over the running threads. At first, we wanted to do a PkBackendPool, which would've contained a pool of "activated" backend instances, but once again we avoided the easy way to do it the right way(tm) (at least that's our impression :P). New solution is that there will be only one backend, but multiple PkBackendJobs, which are submitted to the backend and executed. A backend job is something like "install X,Y" or "get me the details of package X". Implementation is going on right now, and Richard is really amazing with that, as he already updated some of the most difficult parts (I'm writing exams, so not much time ^^). Of course this is still not done yet. There will be a PackageKit release of the new 0.8.x series we've been working on the last weeks. This release will already contain many of the SoC improvements, but I'd like to warn you not to use it in stable distributions. As soon as that is done, the PkBackendJob thing will be merged & tweaked. - A lot of work from backend author will be needed too. After PK is working properly (and probably even before all pieces are at place) I'll go into SC again to fix some issues which were bothering me a long time already. At time, PK is the number-one priority, because without doing the work on PackageKit, a well-working Software-Center is impossible. I haven't seen that coming when I started my SoC, but hey, the changes are awesome! Many other projects will also benefit from them, as there are already some other efforts to write a SC on top of PK. (but they're all in a pretty early state) Next time, I won't write that much text, I somehow always feel the need to explain every single step - probably a sideeffect from working on cross-distro projects :-) Expect some more news and a blogpost soon after I finished exams :-) (I wanted have written a blogpost a month ago already, and the text is nearly done...) If you have questions, please ask or catch me on IRC (ximion, Freenode) - I'll be 100% available efter 6th July again :-) Cheers and thanks for reading! Matthias -- To unsubscribe, e-mail: opensuse-project+unsubscribe(a)opensuse.org To contact the owner, email: opensuse-project+owner(a)opensuse.org

1 0

[opensuse-project] Weekly Report - Upstream Tracker
by N B Prashanth 25 Jun '12

25 Jun '12

Hi, Last week was spent on rewriting the python code base. The code is now based on classes and each of the supported methods (httpls, ftpls, etc) is now a separate class which derives from a common base class. This supports addition of new methods at a later stage. Checking for upstream packages upstream (on openSUSE repos for openSUSE packages) and on sourceforge is not yet implemented. The new scripts were tested with the upstream-tracker.txt file which was previously used as the source of records (currently replaced by the Rails framework). I plan to complete the python code work by adding the Sf and Upstream classes and integrating it with the rails server this week. I also plan to start working on implementation of custom regexp in the URL fields. This would later help with DEHS imports. -- Regards, N.B.Prashanth -- To unsubscribe, e-mail: opensuse-project+unsubscribe(a)opensuse.org To contact the owner, email: opensuse-project+owner(a)opensuse.org

1 0

[opensuse-project] campaign free software foundation.
by Victor hck 24 Jun '12

24 Jun '12

Hello. I hope to make this question in the right palce. Sorry if I'm wrong. Just a question: Must opensuse join to this campaign? http://www.fsf.org/campaigns/secure-boot-vs-restricted-boot/statement Debian has joined. And I think that is a way to say that we are the owner of our hardware. Not other companys that want to "protect" like a father or like a "big brother" we are open, and want a open hardware, not a restricted one! Only my opinion... I have joined and signed Thank's all ! -- To unsubscribe, e-mail: opensuse-project+unsubscribe(a)opensuse.org To contact the owner, email: opensuse-project+owner(a)opensuse.org

1 0

[opensuse-project] Thoughts on the UEFI fee?
by C 24 Jun '12

24 Jun '12

Swapnil has written an interesting blog post about the whole RedHat and UEFI thing that has been floating in the last day or so... http://www.muktware.com/3699/secure-boot-uefi-fedora-red-hat-99-ubuntu-micr… What are we as openSUSE going to do here? Do we pony up the $99 for the key registration fee? (my vote would be yes) Do we ignore it? Has anyone thought about this yet? C. -- openSUSE 12.1 x86_64, KDE 4.8.3 -- To unsubscribe, e-mail: opensuse-project+unsubscribe(a)opensuse.org To contact the owner, email: opensuse-project+owner(a)opensuse.org

29 138

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

21 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-project+unsubscribe(a)opensuse.org To contact the owner, email: opensuse-project+owner(a)opensuse.org

1 0

[opensuse-project] COSCUP
by Jos Poortvliet 20 Jun '12

20 Jun '12

Heya all, You might know we've got COSCUP coming - and the CfP is officially closed but we can surely still use a few more proposals to have something to choose from. So if you want to talk about openSUSE at COSCUP in Taiwan, submit a proposal! http://news.opensuse.org/?p=13126 Send proposals to cfp(a)opensuse.org please. I also want to mention that you can ask the openSUSE Travel Committee for financial support for going there - it's why we have a OTC! Especially speakers are very likely to receive travel sponsorship. See http://en.opensuse.org/openSUSE:Travel_Support_Program /Jos

1 0

[opensuse-project] Improving the bug management lifecycle/process
by Jim Henderson 20 Jun '12

20 Jun '12

OK, so this is something I'd like to start trying to get my arms around so we can have a more comprehensive approach to dealing with bug reports and increase the rate of resolution as well as the follow-up rate when additional information is needed. It seems that we have a few areas that we should be looking at: 1. There should be some sort of "screening" that takes place before a bug is accepted - to ensure that the devs aren't seeing multiple copies of the same bugs. I think it's fair to say that those who write code would far rather *write code* than try to sort through duplicate bug entries. While it's likely there still would be dupes with a screening process, the incidence should be reduced. 2. There needs to be more of a "human" reply, especially on older bugs, that are being addressed. Looking at the current Bugzilla stats, I see that (for example) 12.1 has 183 bugs in a "NEEDINFO" state - there needs to be some sort of consistent follow-up to ensure that the info needed to fix the issues is provided, and if it isn't and the information can't be obtained (because the issue cannot be duped, those looking at it don't have the necessary hardware, etc), then the bug needs to be closed. 3. For older bugs, (such as on 10.3-11.3, which there are still open bugs on), a determination needs to be made as to whether the current supported releases have those issues, and if they do, the bugs need to be updated. If they don't, then the bugs need to be flagged in an appropriate way. 4. It would be extremely useful, I think - especially for the non-techie audience - to put some specific training together on things like (a) how to submit a bug and include the relevant information, (b) what to expect with your bug and how to monitor progress, (c) how to provide additional information when requested (and what to do if you've upgraded/moved to another version/changed distributions/decided to go back to Windows/MacOS/ whatever) so the bug can continue to be evaluated by those evaluating it. Ultimately, the goal of this project is to increase resolution rates, reduce the time to resolution as much as possible, and to visibly improve the bug resolution process so more people don't perceive (correct or not) that reporting bugs is useless because they don't get resolved (and actually, looking at the stats on bug status, I think it's pretty unfair to say bugs aren't getting resolved. I see, for example, that of the reported bugs on 11.1, for example, over 3/4 of the bugs are marked as resolved.) And overall across all releases of openSUSE, and SUSE Linux Professional/ SUSE Linux from 8.2 on, the bugs marked resolved are 13026/18285, which is nearly 3/4. 75% isn't bad (the Pareto rule is 80/20, and on 11.1 we're actually around 78% "resolved"), but I'm sure that if we can guide the process and streamline it, we can increase that. Of course those are just rough statistics and the reason bugs are marked as 'resolved' isn't included in that - and there is a further breakdown that can be done that might help identify trends that would be useful. There's clearly more that we should be looking at, but these four areas are a good place to start. For my own part, I'm willing to do more than talk and discuss the ideas, but it's going to take more than just one person working in his spare time to move this along. I also think something similar to this should be done for FATE, but that's perhaps a topic for another day. :) Jim -- Jim Henderson Please keep on-topic replies on the list so everyone benefits -- To unsubscribe, e-mail: opensuse-project+unsubscribe(a)opensuse.org To contact the owner, email: opensuse-project+owner(a)opensuse.org

19 101

[opensuse-project] [gsoc] osc2 client - summary of week 3 and 4
by Marcus Hüwe 19 Jun '12

19 Jun '12

Hi, here's a small summary of the 3rd and 4th (coding) week . First of all I wasn't able to do lots of work in week 3 and 4 so I'm still working on the new build module for the osc2 library. The initial plan was to copy/reuse some of the existing modules from the (old) "osc" like the cpio [1] and packagequery modules. But I decided to refactor/rewrite cpio module for the following reasons: - "save" disc space: In our scenario we retrieve a cpio archive from the api (which contains binary packages for example). The old cpio module expects a filename in order to "unpack" the archive - that is the file has to be stored on disc first. Consequently approximately 2 * <archive size> of free disc space is needed. The new idea is that we pass a file-like object (in our case an object which inherits from "AbstractHTTPResponse") to the cpio module and unpack the archive "on the fly" (without storing the http response on disc first). - have testcases: The old cpio module has no testcases (because some time ago I didn't follow the TDD approach;) ). For nearly all modules in osc2 there exist testcases (white-box tests) thus it would be nice if we have some testcases for the cpio module, too (theoretically we could add some black-box tests (the current methods aren't really testable thus white-box tests aren't possible)). - have a nice pythonic interface: The new interface will look like this: from cpio import cpio_open # let "f" be a file-like object (for instance a http response) with cpio_open(fobj=f) as cpio_archive: for a_file in cpio_archive: # store file (with correct permissions etc.) in os.curdir a_file.write(os.curdir) # alternatively it's also possible to read some data (instead of # writing it to disc) via a_file.read(len) We will also support a plain filename in cpio_open. Currently the cpio module will only support the "new ascii" (ascii SVR4 no CRC) format and regular files (that's sufficient for our needs). But it will be possible to simply pass in a class for a different format (that is no code has to be altered in order to support a new format). Finally this will be finished by the end of this week. If you have any questions or suggestions please tell me:) Marcus [1] https://github.com/openSUSE/osc/blob/master/osc/util/cpio.py -- To unsubscribe, e-mail: opensuse-project+unsubscribe(a)opensuse.org To contact the owner, email: opensuse-project+owner(a)opensuse.org

1 0

[opensuse-project] 12.3 timing?
by Greg Freemyer 17 Jun '12

17 Jun '12

Coolo (or other), If 12.2 does slip by a couple months, what happens to the timing for 12.3? Does is stay where it was, or slip to 8 months after the 12.2 release? fyi: I'm more curious than pushing for one answer or the other. It just seems that how you handle the freeze will impact how the above works out. Thanks Greg -- To unsubscribe, e-mail: opensuse-project+unsubscribe(a)opensuse.org To contact the owner, email: opensuse-project+owner(a)opensuse.org

6 8

[opensuse-project] fdisk project - GSoC weekly report 4
by Davidlohr Bueso 17 Jun '12

17 Jun '12

Hi, So, what's been done this week: - Sent out a patchset that adds MBR buffer support to the API - Sent out a patchset that adds device geometry support to the API. This also maintains the legacy CHS addressing for flexibility/compatibility, yet the fdisk program will only use LBA as of next year. - General cleanups Thanks, Davidlohr -- To unsubscribe, e-mail: opensuse-project+unsubscribe(a)opensuse.org To contact the owner, email: opensuse-project+owner(a)opensuse.org

1 0

[opensuse-project] Deployments in North/Central America
by Bryen M Yunashko 15 Jun '12

15 Jun '12

Hi folks, For the upcoming openSUSE Summit in September (see http://summit.opensuse.org) we are considering setting up a panel with guest speakers from companies/organizations that have deployed openSUSE in their environments. We have a small list of organizations that we know of in the U.S. It would be nice to get a larger list to determine who to ping to invite. If you know of deployments, please feel free to contact me so I can add it to the list and determine if an invitation is warranted. Thanks! Bryen M Yunashko openSUSE Project -- To unsubscribe, e-mail: opensuse-project+unsubscribe(a)opensuse.org To contact the owner, email: opensuse-project+owner(a)opensuse.org

3 3

[opensuse-project] Announce: Delaying 12.2
by Stephan Kulow 14 Jun '12

14 Jun '12

Hi, Those of you who read opensuse-factory mailing list too, will already be aware, but for those who aren't, I would like to make it more official: We won't be able to release 12.2 in time. We didn't catch up with the slip of the milestones and beta, so I can't release RC1 now - and delaying RC1 means delay of 12.2 too. As I don't want to move 12.2 release into august due to vacation time, my thinking about rescheduling is this: - next week I will release what I have as 12.2-Beta2 - after that we will split away openSUSE:12.2 from factory to put it under deep freeze for pure bug fixes. - Mid of July we can have RC1 - August will see more updates, but no real action - Release mid of September Greetings, Stephan -- To unsubscribe, e-mail: opensuse-project+unsubscribe(a)opensuse.org To contact the owner, email: opensuse-project+owner(a)opensuse.org

7 10

[opensuse-project] Re: [opensuse-factory] openSUSE 12.2 deserving of attention?
by Jos Poortvliet 13 Jun '12

13 Jun '12

On Tuesday 12 June 2012 18:20:24 Genix Info wrote: > IPv6 and DNS: > > http://lists.opensuse.org/opensuse/2012-06/msg00010.html > > I understand. But you said that there needed to be developed to help, I > thought my suggestions of features and bugs would be forwarded to the > developers. This IS the developer list and feature requests go to openFate - fate.opensuse.org or in case of bugs, bugzilla. In any case, sorry if I was unclear. I was looking for input from the developers on what has changed in the release, not asking from users what they would like to see as we're way too close to release to be able to do any of that. ;-)

1 0

[opensuse-project] Installation Media
by Graham Anderson 12 Jun '12

12 Jun '12

List, Coolo's recent reports regarding the growing size of our installation media highlight one area where there appears to be no obvious technical solution. We are simply running out of room to squeeze bits into the common capacity optical media that our users are accustom to, namely the CDROM capacity. The pressing concern of this would appear that by increasing the image size for installation via USB fobs or DVD, we might alienate existing or future users that simply cannot easily download an image of growing size. I wonder if we can perhaps fall back to more low-tech methods to help in this regard. We have a network of user groups, ambassadors and such like. I wonder if we could instigate a program of distribution whereby our users can volunteer to physically burn to disc our latest and then use the relatively cheap national postal services to send the media to our users with low bandwidth connections. To take it further, optical media while in decline, is still a very profitable market. I'm sure anyone who has burnt discs has had their experience of the longevity of the media. Perhaps we can approach one of the better quality optical media manufactuers and ask for discounts of scale. This would allow us to send spindles of writable discs to areas where we might have a user group or ambassador but has a generally low level of connectivity. I'm aware of the previous and as I understand now defunct program that canonical sponsored to distribute media, but I have no insight as to it's effectiveness or why it has been stopped. I am suggesting something slightly different, this would hopefully be a community driven effort. It's not a perfect solution by any means, but I can't think that our increasing need for more space will allow us to use CDROM size media in future. Thoughts? Cheers the noo, Graham

9 12

[opensuse-project] [reminder] openSUSE Project Meeting tomorrow at 20:00 UTC
by openSUSE Meeting Reminder 12 Jun '12

12 Jun '12

Hello all, The biweekly project meeting will be held tomorrow at 20:00 UTC in #opensuse-project on freenode. Everybody is invited to join and participate! Find out what time the meeting will be in your timezone: http://timeanddate.com/worldclock/fixedtime.html?day=13&month=6&year=2012&h… Agenda of the meeting: http://en.opensuse.org/openSUSE:Project_meeting#Agenda_for_the_next_meeting If you cannot participate and want a specific question to be answered during the meeting, please add your question to: http://en.opensuse.org/openSUSE:Project_meeting#Questions_Section Minutes and logs of previous meetings can be found at: http://community.opensuse.org/meetings/opensuse-project/ Thanks, -- openSUSE Meeting Reminder -- To unsubscribe, e-mail: opensuse-project+unsubscribe(a)opensuse.org To contact the owner, email: opensuse-project+owner(a)opensuse.org

1 0

[opensuse-project] Upstream Tracker - Week 3
by N B Prashanth 11 Jun '12

11 Jun '12

Hi, This is my weeekly report for the upstream tracker project. What's been done last week: 1. Edited the existing python scripts, written by vuntz, to read and write data from/to the Rails Server. 2. Reduced complexity of user input form. 3. Fixed a few small bugs - Such as the method field reverting to default on update etc. What's planned for this week: 1. The updates to the python scripts were more of a quick hack. We need a class to handle data - Reading and Writing to the rails server. Later on, this model can be updated when authentication is enforced. 2. The entire script needs an Object Oriented approach. So the scripts would be rewritten by using a base class and derived classes (one for each download method). 3. Try to implement GUI for paper trail. -- Regards, N.B.Prashanth -- To unsubscribe, e-mail: opensuse-project+unsubscribe(a)opensuse.org To contact the owner, email: opensuse-project+owner(a)opensuse.org

1 0

[opensuse-project] fdisk project - GSoC weekly report 3
by Davidlohr Bueso 10 Jun '12

10 Jun '12

Hi, So, what's been done this week: - Got the entire disk topology discovery and usage added to the API - Working on disk geometry, and more important, replacing CHS addressing with LBA. Hopefully these patches will be done soon. - General cleanups Thanks, Davidlohr -- To unsubscribe, e-mail: opensuse-project+unsubscribe(a)opensuse.org To contact the owner, email: opensuse-project+owner(a)opensuse.org

1 0

[opensuse-project] led display Suppliers shared photos with you
by led display Suppliers 10 Jun '12

10 Jun '12

Dear Mr/Miss, Still be puzzling about looking for best led display supplier? Now it will be miles easier working with KEROSA! Here you can find competitive price and excellent quality with a best mix. We"ve been in led display career for many years. We know your market and your country well. Our business is flexible which something is more likely to be a friend chat. We never waste your time. Our conversation will be very efficient base on our good communication. Please reply as soon as possible .if you are working on some led display project. We are ready to make you a satisfied offer! Samuel Shezhen Krosa Techology Co.,Ltd. Address: Building 3,Park,Guanguang road,Bao"an District,Shenzhen,China. post 518000

1 0

[opensuse-project] AppStream/SC/PK GSoC report #2
by Matthias Klumpp 09 Jun '12

09 Jun '12

Hi! Again some news about my project on making the Software-Center (forked from Ubuntu) cross-distributional, usable and a pleasure to use ;-) Right now I'm still at improving PackageKit, because PK is the key component to make the SC work great. Last week I did many improvements on PK and also introduced a package-sqlcache which can be used to fetch package details extremely fast. I've seen this as the only way to improve the current situation and make it possible to read package data fast & in parallel to other running transactions. I did not really like the database cache, and many people agree with the point that a cache is not very nice. Daniel Nicoletti (Aptcc dev, Apper maintainer) suggested a session-daemon approach to solve the parallelization issue, which Richard didn't like. I didn't like it too very much. As cache was bad and parallalization not easy to have, I suggested to write an abstraction library to access package databases directly by resuing existing backends. This way, DBus would also be avoided (Telepathy doesn't send logs over DBus because of speed too, so I thought this was a good idea for the large amount of data) Daniel didn't like my idea, as Qt tools would then need to interface with a GLib access library. Richard didn't like my idea too, as it was "too complicated" and instead suggested to implement a feature which we tried to add about a year before too, but then the issue I wanted to solve with it was solved with another solution, so we didn't need it back then: parallel transactions. Parallel transactions means we would be able to execute read-only actions which don't need a database lock in parallel to other transactions. This idea was disliked by both me and Daniel, I first was against it because we would force backend maintainers to implement a threadsafe backend and probably change their package manager, Daniel didn't like it because Apt, the Debian package-manager was not threadsafe. To solve all of this, spwaning a new process and doing IPC was suggested, but I didn't like that every backend had to implement an own solution for that and wanted a generic solution (as probably other backends had this problem too) and Daniel didn't like to do extensive IPC in a backend. When the discussion was close to a deadlock, Michael Vogt (Apt maintainer) said that it would be possible to change Apt to be threadsafe for most transactions. This suddenly removed nearly all arguments against parallel transactions, so I'm now working on a implementation of parallel processing for PackageKit. It is important that backend maintainers make changes on their backends to support parallel transactions, otherwise the backends will fail miserably as soon as parallel transactions are implemented. So I put some hours on thinking about all (hopefully all!) corner cases which could possibly appear before implementing parallelization. I added some new backend API which PackageKit backends need to use to make this feature work. I also extended our backend porting guide to describe how backend maintainers should adjust their backends to continue working. The porting guide contains information how to proceed on backends which are threadsafe as well as those which aren't. Our top-maintained backends (Yum, Zif, Aptcc) will be ported soon. As soon as I have a working implementation of parallel transactions I will also write a mail to PackageKit development list as a reminder for people to please adjust their backends to the changes. The parallel transactions approach is great, as it will solve the most important issues without creating an extra cache. Also, it is something which is done right(tm), without any workaround or ugly hack. Problem is that backend code has to be touched, but we already broke backend API for some other improvements and the changes aren't too complicated. With parallel transactions, the SC will be able to GetDetails() of a package while running InstallPackages() in parallel. We still need a simple cache to improve speed, but the cache was present for a very long time anyway, is small and can be created quickly. This feature will also reduce waiting times in PackageKit frontends and in general improve user experience in all PK clients. Problem is that not all backends will support that, for example Fedora's yum can't run transactions in parallel. Those backends will still have to run a queue of transactions and therefore the SC will not work as great on these distributions as it does on others. But it would also not work very well without PackageKit, it's a problem of the package-manager. Solution for Fedora in this case would be switching to Zif for example. I think all other issues can be adressed too. I'm glad that we will have a working and sane solution for this issue soon, which will make PackageKit fast as hell - if you like experimental, breaking software you can aleady try the PackageKit master branch ;-) Finally some other things: I'll have exams in a few weeks, and unfortunately I don't study informatics/computer science but molecular biomedicine, which means I have to learn anatomy, histology, biochemistry and physics the next weeks to pass the exams. I will have to reduce my work on this SoC project a little during these weeks, but I won't stop of course, I'll just be a bit slower. After I hopefully passed the exams (eeh...) I can work days and nights (probably more during nighttime) on PK and SC. This is just FYI. As there seems to be a very high interest in my SoC by various people: You can always catch me on #PackageKit, #freedesktop or #opensuse-project (and various other channels) on IRC, my nickname is ximion. I'll try to answer any questions as good as I can :-) Or just reply to this mail :P Bye! Matthias -- To unsubscribe, e-mail: opensuse-project+unsubscribe(a)opensuse.org To contact the owner, email: opensuse-project+owner(a)opensuse.org

1 0

[opensuse-project] AVG virus scanner. How did I actually install it?
by Chris Jones 09 Jun '12

09 Jun '12

4 5

[opensuse-project] LTP GSoC report
by Marioh mrs 06 Jun '12

06 Jun '12

Hi all, Since this is my first report, i will summarize all the work done till now for the Linux Test Project GSoC project. As proposed, the first phase of the project is to document/fix and test the test library, therefore the work started with an easy task/file in order to get up to speed with how things are done. The first patch-set was: 1) Indentation and coding style fixes on /lib/str_to_bytes.c as well as /include/str_to_bytes.h Fixed broken indentation as well as replaced the old K&R function declarations. https://github.com/linux-test-project/ltp/commit/9a769aae5e3db79c1189c2c9da… 2) Renamed /lib/str_to_bytes.c and /include str_to bytes.h The str_to_bytes files have been renamed to bytes_by_prefix in order to make it easier for anyone to understand the purpose of the file, the functions of the file have also been ranmed accordingly. Furthermore any call to the file or its functions by other functions, manpages etc. have been modified to comply with the new names. https://github.com/linux-test-project/ltp/commit/1475f67b0c77392df6d5bca84c… 3) Changed nconv variable from long to int in /lib/bytes_by_prefix.c According to sscanf man page the return value is int therefore the holding variable should be int as well. Also changed the loop variable name of the main method from ind to i in order to better represent that it is just a loop variable. https://github.com/linux-test-project/ltp/commit/3d3e94e7c0f056041a71389858… After this patch-set, the next goal was to create an "automated" test for this file in order to ensure reliability and enable us to easily detect if something breaks, this test file also lead to a logical fix on the file being tested. The patch-set: 1) Return -1 on negative input/output (/lib/bytes_by_prefix.c) -1 is returned as error value therefore it wouldn't be correct to allow negative numbers to be parsed and returned as normal multiplication. Therefore a check has been added in order to return any negative output as -1 (error). https://github.com/linux-test-project/ltp/commit/5f017a0976a32445b0925bf365… 2) Created an automated test for the /lib/bytes_by_prefix.c Created a test for the bytes_by_prefix.c file in order to make sure that everything works well and make it easy to test if some change breaks something. The UNIT_TEST main method from lib/bytes_by_prefix.c has been removed as it isn't needed anymore nor compiled by default. Necessary changes in the makefiles have been done. https://github.com/linux-test-project/ltp/commit/33bb7130addb59c28f0c6834aa… Now i am working on the much more used part of the library the tst_* interface/files and hopefully the next patch-set will be sent for review/commit within a few days. To conclude, this is a great experience, learning to contribute to open-source projects and collaborating with other people that i have never met :) I would like to thank my mentor Cyril Hrubis for his invaluable help showing me around the project, sharing some nice tricks and being very helpful by just pointing me to the right direction as well as always replying very fast to my questions :) great guy. P.S. You can watch the project development on the ltp-list: http://sourceforge.net/mailarchive/forum.php?forum_name=ltp-list -- Marios Makris -- To unsubscribe, e-mail: opensuse-project+unsubscribe(a)opensuse.org To contact the owner, email: opensuse-project+owner(a)opensuse.org

1 0

[opensuse-project] Re: [opensuse-factory] openSUSE 12.2 deserving of attention?
by Jos Poortvliet 05 Jun '12

05 Jun '12

On Mon, Jun 4, 2012 at 6:46 PM, Genix Info <genixinfo(a)gmail.com> wrote: > Jos Poortvliet, please resolve these bugs and features: I don't understand why you ask me to do that? I'm sure the people working on those things would be happy with merge request. I'm barely able to build a basic package on OBS so I surely won't be able to do any of that... I understand you care about these things but off-topic replies to random mails won't exactly get you anything... (Incidentally, I personally don't care for any of them and IF I could do such work and would have time for it I'd work on different things). Cheers, Jos > OpenSUSE Linux, including SuSEfirewall2, not has full support for IPv6 only. > > http://forums.opensuse.org/english/get-technical-help-here/network-internet… > > Bug 742758 - openSUSE Linux 12.1 LXDE x86_64: /home partition problems: > > Joined on Bugzilla: https://bugzilla.novell.com/show_bug.cgi?id=742758 > > Add BleachBit installed by default, the current version: 0.9.2. > > Top list openFATE: > > > 1 - Update Documentation: > > https://features.opensuse.org/313311 > > 2 - Add the packages: linux-atm-lib, smpppd and WvDial in: Live CD, USB > Live...: > > https://features.opensuse.org/312580 > > > This is here to do just that: > > Now please add smpppd (Smpppd - openSUSE) by default already installed, > configured and ready to use in version 12.2. > > 3 - Mount NTFS partitions user-writeable by default: > > https://features.opensuse.org/310229 > > > > > > > > > > I expect a response. > > > > > > > > > > 2012/6/3 Jos Poortvliet <jos(a)opensuse.org> >> >> Hey all, >> >> If you think there's something cool coming in openSUSE 12.2 which deserves >> some attention of press and users, add it to this page: >> http://en.opensuse.org/openSUSE:Upcoming_features >> >> If you notice something there which is wrong - please fix it! >> >> Note that you don't have to be a developer or packager for either of the >> things above - if you're an user reading this list but you happen to know >> of something that's new and missing, just add it! >> >> Links to explanations of the feature or new or much improved package are >> appreciated. We'll use this page for the release announcement and articles >> about the new release. >> >> If you want to help with anything around promo, tell us on the opensuse- >> marketing list! >> >> Let's make 12.2 rock. And let's make sure the world KNOWS it! >> >> Hugs, >> Jos > > -- To unsubscribe, e-mail: opensuse-project+unsubscribe(a)opensuse.org To contact the owner, email: opensuse-project+owner(a)opensuse.org

1 0

[opensuse-project] CFP for FOSS.in is out
by Manu Gupta 05 Jun '12

05 Jun '12

Hey All, CFP for FOSS.in is out. Please look into it and if you can look into it and submit a talk, it will be great. More details can be found at http://foss.in/participate/call-for-participation Thanks a lot -- Regards Manu Gupta -- To unsubscribe, e-mail: opensuse-project+unsubscribe(a)opensuse.org To contact the owner, email: opensuse-project+owner(a)opensuse.org

1 0

[opensuse-project] Upstream Tracker - Week 2 - Report
by N B Prashanth 05 Jun '12

05 Jun '12

Hi, This is my work during last week for the Upstream Tracker Project. 1. Simplified forms for user input. 2. Added Search feature to search for Results. 3. Disambiguation page for multiple records with same name. 4. Started working on paper trail for managing version history. This week, I plan to 1. Create a view for looking at record history and undo any modifications. (This will be restricted to people who have access - Username & Pwd) 2. Integrate existing Python Script to work with the Rails server. -- Regards, N.B.Prashanth -- To unsubscribe, e-mail: opensuse-project+unsubscribe(a)opensuse.org To contact the owner, email: opensuse-project+owner(a)opensuse.org

1 0

[opensuse-project] AppStream/SC/PK GSoC report #1
by Matthias Klumpp 05 Jun '12

05 Jun '12

Hi! This is my first report of the work I'm doing on AppStream and PackageKit / the Software-Center. It took a little longer to write it, university is giving me a hard time, sorry for that! Before the SoC development started, I already familiarized with the SC code and learned a bit more Python, which will definitely help a lot :-) I ported the SC from using PkClient to PkTask, because PkTask is a much more generic interface and the thing we want to use in the SC. Unfortunately, the SC was still extremely slow, so I applied some PackageKit-tricks to make it over 420% faster, I introduced some new PK API for that. Still this was not enough: If you install software, you are - due to PK's design - unable to also query package details, which makes it impossible to view application details while installing stuff. This makes using the SC a pain and also has some problems when it comes to searching stuff. In the last two weeks, I discussed all these issues with Richard Hughes, the PackageKit maintainer. I wrote a prototype of a SQLite based package-cache, which will make querying data super-fast and will make it possible to do this in parallel to PK transactions. First, the cache was super-slow, but with some optimizations in PkPackageSack routines, it now runs with acceptable speed so we can use it. I also found some other optimizations together with Richard, which will make PK itself a lot faster on some operations. (it will save from a few msecs up to 10secs, depending on what you're trying to do) In the process of talking about changes and reviewing patches and suggestions, Richard decided that it's time now to _really_ break stuff and make it more sane. So right now we're doing a new PackageKit 0.8.x series, which will contain lots of cool improvements, not only relevant for the stuff I want to do, but also for other new features, like systemd-offline-upgrade. My changes are already merged upstream and I will do a public API to access the cache now, after discussing that upstream. Also, there are some other changes on PKs DBus-API I and some other people would like to have, discussion is going on there right now. We're also improving backend interaction and broke plugin API, so there's lots of stuff going on right now which will make developing a SC based on PackageKit a lot easier. At time, all PackageKit backends are broken and there's lots of stuff which needs to be fixed and even more to be discussed. Doing cross-distro-work is sometimes even more discussion than coding, but I am certain right now that we will have a usable AppStream Software-Center with the end of my SoC project. If you read through this now, I'd like to ask you if you have anything you want to do with PackageKit (which is not very backend-specific) and haven't been able to do until now. - If there is any of these issues, we might now be able to fix it. Next steps are even more discussion and work on PackageKit to get the API right, as well as some changes on SC and probably a C++ implementation of AppStream Xapian generator, so other implementations of an AppStream-SC are possible (hey, KDE!) and we can use it even without the SC. Also, backend developers, please fix your backends soon! I want to find people responsible for the Zypper backend, so they can take a look at it and adjust it to our changes. (I have no knowledge about Zypper, and developing in a VM is a pain, but I could of course make some changes by myself later, if the basic stuff is working) Test results about overall performance is helpful too. -- Overall the start of this SoC was promising. First after experiencing the first issues, I thought it might become extremely difficult to complete this project, as there were many issues to work around, but now problems are solved and we're really doing amazing stuff! Working with Richard and the PK crows is a pleasure, as always and very productive. I'm looking forward to the next weeks, as everything is now working as planned again. :-) (Especially I need feedback from other distributions later) Thanks, Matthias -- To unsubscribe, e-mail: opensuse-project+unsubscribe(a)opensuse.org To contact the owner, email: opensuse-project+owner(a)opensuse.org

3 9

[opensuse-project] Travel Support Team Expands to Help With Marketing Materials
by Izabel Valverde 04 Jun '12

04 Jun '12

Dear openSUSE people, Right now, the openSUSE Travel Support team helps you out with travel costs for representing openSUSE at events. From now on, the team will also reimburse booth costs and marketing material costs up to a limit. We'll be able to support expenses up to € 100 in Europe or $ 100 in the US and everywhere else. You can use this to print stickers, t-shirts, flyers and many other things in addition to the materials we can send you with the DVD’s. There are many materials available in our github repository on https://github.com/openSUSE/artwork - feel free to modify and improve any of that and submit changes back to our repo! The process will work the same way as the Travel Support: you let us know in advance; we agree on an amount and you get the money back based on the receipts. More info: http://en.opensuse.org/openSUSE:Travel_Support_Program The process: * Send the request to travel-support(a)opensuse.org * Tell and show us what you want to produce, why and for what event. * Wait patiently to get questions or suggestions about your request * Any extra information can be required, please provide it asap * Expect a confirmation of your approval, or if it's taking too long, feel free to ping any member of the committee The reimbursement process: * After the material produced take a picture from what you did. * Send the receipts, pictures and form filled to travel-support(a)opensuse.org * The receipts submitted for reimbursement must contain the itemized expenses We’re happy to improve on our support for the ambassador activities for openSUSE and welcome any suggestions for further improvements! Thank you for your support, The Travel Support Team -- Izabel Valverde openSUSE Travel Support Program http://en.opensuse.org/openSUSE:Travel_Support_Program http://news.opensuse.org/ -- To unsubscribe, e-mail: opensuse-project+unsubscribe(a)opensuse.org To contact the owner, email: opensuse-project+owner(a)opensuse.org

1 0

[opensuse-project] openSUSE 12.2 deserving of attention?
by Jos Poortvliet 03 Jun '12

03 Jun '12

Hey all, If you think there's something cool coming in openSUSE 12.2 which deserves some attention of press and users, add it to this page: http://en.opensuse.org/openSUSE:Upcoming_features If you notice something there which is wrong - please fix it! Note that you don't have to be a developer or packager for either of the things above - if you're an user reading this list but you happen to know of something that's new and missing, just add it! Links to explanations of the feature or new or much improved package are appreciated. We'll use this page for the release announcement and articles about the new release. If you want to help with anything around promo, tell us on the opensuse- marketing list! Let's make 12.2 rock. And let's make sure the world KNOWS it! Hugs, Jos

1 0

[opensuse-project] fdisk project - GSoC weekly report 2
by Davidlohr Bueso 03 Jun '12

03 Jun '12

Hi, So, what's been done this week: - Sent a patchet that gets rid of a good number of global variables and uses them from function parameter, preparing for device topology and geometry integration. - Implemented device topology discovery in the internal API - some regressions were introduced handling physical and logical misalignment, this is currently being worked on. I'm hoping to send out the patchset by today. - General cleanups. Thanks, Davidlohr -- To unsubscribe, e-mail: opensuse-project+unsubscribe(a)opensuse.org To contact the owner, email: opensuse-project+owner(a)opensuse.org

1 0