This is a follow-up on my earlier post on zypper tab-completion.
Completion for package-names just made its way into git (thus soon will appear in Factory aka Tumbleweed) after ~6 weeks of back and forth exploring different approaches.
And it is super-fast 🙂
If you do not want to wait, you can use OneClickInstallCLI http://multiymp.zq1.de/zypp:Head/zypper
with allowing some vendor changes for libzypp and libsolv
Hi Geekos, here a small summary of our Thursday February 19th openSUSE miniSummit event here at SCale 13x.
Located in Century AB room, a 80 seats room. The average attendance rate was varying between 50% and 85%.
Qualifying the attendance 50% or more were not related to SUSE / openSUSE, which was a good experience of question and feedback.
The day started by a talk about openSUSE / SUSE Xen and openstack by Peter Linnel and Russel Pavlicek.
One hour later Manu Gupta has presented all the bolts and nuts about GSOC at openSUSE.
We then go for lunch, and corridor exchanges.
I’ve opened the afternoon with my talk “them + me = we” about breaking mythic frontier
Then just after a small break, Mark Fasheh member of filesystem SUSE Labs group has talk about the project Duperemove: dedupe on btrfs (have a look on github the source are there, and package available on obs)
The day continue with a Town Hall talk co-animated by myself and Peter running an open discussion with attendees. With interesting remarks and feedback from openSUSE users, and also complete foreigners. For example, the way systemd was introduced in openSUSE distribution was appreciated (having choice during 2 versions). It was an unstressfull, open and positive exchange.
To follow, Bryan Lunduke and Peter animated a talk about “the 10 things you would love about SUSE and openSUSE if you only you knew…”
I did really enjoy the way they numbered the slides …
Freschy, punchy, funky, the kinda talk I would like to see again at OSC15.
To finalize the day, Markus Feilner for Linux Magazine (de) talked about openQA.
I found interesting the perfect mix we’ve done between openSUSE and SUSE during this day, confirming the excellent partnership we have.
Let the sponsors of this day be warmly thanked to make it happened.
Links :
SCale picture album day 1 : by Françoise on G+
openSUSE miniSummit day album :
Bruno’s Album on G+
Follow the news on G+ channel
Stay tuned for more news during this week-end.
Again this year the thirteen annual Southern California Linux Expo is in the starting block.
During 3 days you will be able to visit us at our booth (38,39,40).
Yeah 3 booths cause we co-run the KDE and Gnome booth.
The exhibition hall open Friday afternoon at 2pm.
Drew and Peter are working as daemon to get everything ready to spread, Doug have brought also quite numerous goodies there. I will do my best to inform you here or follow my G+ channel
Whatever the way you come, bring your feet there and shake hands.
On Thursday, no one has to miss our full day of openSUSE mini-summit, room Century AB.
There will be interesting talks and also a full green hallway, We’re looking forward SUSE’s team, working together in this promising adventure.
On our side Geeko is ready to cross 9.000 kilometers tomorrow.
Hey cool first time in the famous Airbus A380…
Demo laptop with Tumbleweed and KF5 is also secured.
See you all in Los Angeles
Hi Fellow Geekos,
This post is a summary of my wish to continue to serve on your behalf on the openSUSE board.
My term has been a short one, as I was appointed to serve out the remainder of Vincent Untz’ term.
While I now work for SUSE (and it has been a fabulous experience), that does not change my view or efforts to contribute to openSUSE. Prior to joining SUSE, as a part of the Sales Engineering team, I was elected to the board for a two year term. To avoid having too many SUSE employees, I had to step down. A rule I completely support.
Having been an openSUSE member long before joining SUSE, I think I have a keen awareness of what the community is about and where we can improve together.
My take is we have an awesome group of contributors who want to see the community grow and prosper. With things like Tumbleweed and OBS, among others, we have shown real innovation and technical leadership in the Linux world. We have arguably one the top distros available. It is solid, polished and usable for a wide variety of use cases. We need to keep the openness and solid collaboration which enables everyone to participate and succeed.
My efforts within openSUSE have been mostly focused on the Open Build Server, maintaining several projects, as well as, being part of the Factory review team.
Going forward, I want to concentrate on reaching out beyond our community to build more awareness of what an awesome distro we have, along with a pretty friendly community. I see other, less compelling, distros getting more visibility than perhaps is deserved.
Along the same lines, my take is we as a community can take a more active role in bringing in new members, who might not be technical folks, but can help in the marketing and outreach. I’ve started a local SUSE group through meetup.com which is a different way to find new users and contributors.
One other reason I wish to remain on the board, is we have a solid working relationship and there is a lot of mutual respect and good collaboration.
No matter who is elected to the board, I am very pleased with the caliber of the folks running and know the community will be in good hands moving forward.
Thank you in advance for your vote!
Peter Linnell
Back on line after several weeks in late, I’ve tried from my best to resolve the case of Factory rolling releases.
After some hacks on the latest Sebastian Siebert beta version (Made in June), I’ve been able to build now BETA fglrx rpm for several openSUSE version.
one day AMD will release or not a stable version. (On my side I prefer to see more efforts made on the free radeon driver.)
This release concern only owners of radeon HD5xxx or above. All owner of HD2xx and HD4xx are really encouraged to use the free radeon driver (which received a lot of improvement in 3.11+ kernels)
This is experimental & BETA software, it could fix issues you encountered (FGLRX not working for openSUSE 13.1),
I would like to have some news about Sebastian Siebert, he’s a essential key for future updates.
This time I was able (even with several weeks in late) to adjust the script to create a build for openSUSE Factory.
But one day something will broke in kernel or somewhere else, and we all need to find a way to fix it.
So if you’re in touch with Sebastian, could you drop me a comment or a private mail?
I would like to continue the good support we created 3.5 years ago, or at least knowning if I’m orphan 🙁
To make things clear about the status of the drivers, it will not be published under the normal stable repository http://geeko.ioda.net/mirror/amd-fglrx.
I’ve created some times ago a beta repository located at http://geeko.ioda.net/mirror/amd-fglrx-beta.
The FGLRX 14.20 beta1 rpm are released for openSUSE version 12.3, 13.1 (+Tumbleweed), Factory
Signer of package my generic builder gpg key at Ioda-Net. (gpg key id 65BE584C)
For those interested by contributing or patches done to last Sebastian version, the raw-src on the server contain all the material used
http://geeko.ioda.net/mirror/amd-fglrx-beta/raw-src.
Admitting you’ve the normal repository named FGLRX, (use zypper lr -d to find the number or name you give it). You have to start by disabling it
so you could fallback to it quickly when new stable version will be published. Open a root console or add sudo at your convenience and issue the following command:
zypper mr -dR FGLRX
To add another repository in the same console as root issue the following command which will install normally the right repository for your distribution
zypper ar -n FGLRX-BETA -cgf http://geeko.ioda.net/mirror/amd-fglrx-beta/openSUSE_`lsb-release -r | awk '{print $2}'` FGLRX-BETA
If you are using Tumbleweed use this one
zypper ar -n FGLRX-BETA -cgf http://geeko.ioda.net/mirror/amd-fglrx-beta/openSUSE_Tumbleweed FGLRX-BETA
Now the update/upgrade process
zypper dup -r FGLRX-BETA
Let the system upgrade the package, and try to enjoy the new beta.
As you might know, we are focusing our development efforts in two fronts, namely openQA and staging projects. As we just started we don’t have fireworks for you (yet) but we did some solid ground work that we are going to build upon.
We are organizing our daily job in openQA into highly focused sprints of two weeks. The focus of the first sprint was clear: cleanup the current codebase to empower future development and lower the entry barrier for casual contributors, which can be translated as “cleaning our own mess”. We created some tasks in progress, grouped in a version with a surprising and catchy name: Sprint 01.
Up to now, openQA web interface was written using just a bunch of custom CGI scripts and some configuration directives in Apache. We missed a convenient way to access to all the bell and whistles of modern web development and some tools to make the code more readable, reliable and easier to extend and test. In short, we missed a proper web development framework. We evaluated the most popular Perl-based alternatives and we finally decided to go for Mojolicious for several reasons:
We’ve now reached the end of the sprint and we already have something that looks exactly the same than what we had before, but using Mojolicious internally. We are very happy with the framework and we are pretty confident that future development of openQA will be easier and faster than ever. OpenQA has mojo!
Another part that we worked on during first sprint was the database layer. The user interface part of openQA use a SQLite database to store the jobs and workers registered in the system. The connection between the code and the database was expressed directly in SQL using a simple API.
We have replaced this layer with another equivalent that uses an ORM (Object-relational mapping) in Perl (DBIx::Class). Every data model in openQA is now a true object that can be created, copied and moved between the different layers of the application. Quite handy.
To make sure we don’t forget anything, we created a bunch of tests covering the whole functionality of the original code, running this test suite after each step of the migration. In this way we have achieved two goals: we now have a simple way to share and update information through the whole system and we can migrate very easily to a different database engine (something that we plan to do in the future).
Over the time, coolo had accumulated quite some scripts that helped him with Factory. Most of them are actually related to something we are doing right now: the staging projects. So in the end we basically migrated all relevant ones to github and one by one we are merging their functionality to staging plugin. We also experimented with test frameworks that we could use to test the plugin itself, selected few and we even have a first test! The final plan is to have the whole plugin functionality covered with a proper test suite, so we will know when something breaks. Currently, there is a lot of mess in our repo and the plugin itself need big cleanup, but we are working on it.
If you want to help but wonder where to start, we identified tasks that are good to dive into the topic and named them “easy hacks”: mostly self contained tasks we expect to have little effort but we lack the time to do right now. Just jump over the list for openQA or staging projects.
For grabbing the code related to staging project, you only need to clone the already mentioned repository. The openQA code is spread in several repositories (one, two, three and four), but setting up your own instance to play and hack is a piece of cake using the packages available in OBS (built automatically for every git push).
If you simply want to see what we are doing in more detail, take a look at progress.o.o, we have both openQA and Staging projects there.
We are having a lot of fun, and we encourage you to join us!
Lately there was some confusion regarding our communication. We, at the openSUSE Team@SUSE are deeply aware that our communication needs to be improved. So in the hope to make everything clear again, here is the summary to clear up what is really going on and what was not happening.
Our team and only our team – openSUSE@SUSE – is going to work on improving ‘tooling’ side of the openSUSE project until August. These changes will benefit openSUSE by making it easier to produce better releases in the future.
Nothing changes for the rest of SUSE. SUSE is not abandoning openSUSE. The rest of SUSE will still do the same things they were doing until now and continue to keep openSUSE awesome. This includes Maintenance, Security, Infrastructure, and many other teams besides the openSUSE Team at SUSE who actively support the openSUSE project.
Our plan is to make sure that future openSUSE releases are easier for everyone to produce. As we grow we could keep putting in more and more full-time release managers (if we find them somewhere), but this approach is probably unsustainable and, more importantly, goes against our desire to empower the community to do more as part of openSUSE.
Therefore, we decided to improve our tools to ensure that making a release is much more straightforward and reliable and we can reduce and distribute the workload needed for integration and release. To make this happen we need time and everyone from the team to work on adapting the tooling side. We also would welcome volunteers to help us with tools and with the following release(s).
With the release date now set in November (mirroring roadmap for 13.1), first milestone should be released in May. That is a perfect oportunity to go to openSUSE Conference in Croatia where we can meet up, gather volunteers to help and discuss how to work. Remember that openSUSE Travel Support is in place to sponsor everyone who needs financial help to get to the event.
Hopefully now we cleared things up a little and we are really sorry again for our poor communication – We’re going to work on it.
Your truely confused openSUSE Team
This week, the openSUSE team blog is written by Agustin, talking about the proposals the team has done for openSUSE development.
A few months ago the openSUSE Team started a journey that achieved an important milestone last Tuesday, Nov 26th 2013. We have worked on creating a picture of relevant areas of the project in 2016 together with some of the actions we think should be taken during the following months to achieve it. To stop working and raise your head once in a while to analyze what is around you and setting a direction is a very good exercise.
The first step was working on data mining. After many hours of analysis, we identified some clear trends that helped us to establish a solid starting point to begin to work with. Once that phase was over (this is an ongoing process, in fact), we worked for a few weeks/months in trying to define that future picture interviewing several dozens of people. We refined that first attempt through several iterations, including many of those who participated in the original round and others who didn’t. Susanne Oberhauser-Hirschoff was the person who drove that process with Agustin.
We soon realized that discussing high level ideas in a community used to “Get shit done” was going to be easier if we complement them with some more down to earth proposals, specially in technical aspects. We cannot forget that, after all, openSUSE is a technical (and very pragmatic) focused community.
So, in parallel with the already mentioned refinement of the big picture, we started discussing within the team the actions needed to take to make the big picture a reality, the openSUSE development version a.k.a Enhanced/New Factory. After many hours of (sometimes never ending) discussions, we agreed on the ideas we are currently being published, together with the motivations behind them.
Another aspect we tried to bring to the discussion has been a strong dose of realism, trying to ensure that whatever we came up to was compatible with the nature of the project. We have also put focus on making sure that the initial proposal is achievable. So as part of community, we understand very well we cannot succeed alone. We need to work with you. So we just opened with the community a process analogous to what we went through within the team. It might be different in form but similar in principles and goals.
These days the proposals are being discussed in different mailing lists. We are collecting feedback, discussing it, summarizing it, adapting the proposal to it … trying to reach agreements before defining what to do next.
We divided the proposal in a series of smaller proposals we are publishing in the project mailing list, where the general community topics in openSUSE are discussed, and/or factory ML, where the more technical discussions take place.
openSUSE Development Workflow
The following articles describe in more detail some relevant (also new) elements pointed in the previous article, since they are new or modify the current process significantly. Some of the articles are in the queue to be published.
There might be an eighth article describing some smaller, still relevant, ideas. After publishing the “content”, we will release one last article providing a information about how to achieve these ideas, describing also our compromise in terms of effort and pointing out the challenges we perceive in the plan from the execution point of view.
We would like to invite you to the debate if you haven’t raised your opinions yet.
update: new image with kernel-3.6 and minimal X11/icewm http://www.zq1.de/~bernhard/linux/opensuse/raspberrypi-opensuse-20130911x.img.xz (103MB)
We got a new armv6 based image for the Raspberry Pi.
This one is only 82MB compressed, so pretty minimalistic.
http://www.zq1.de/~bernhard/linux/opensuse/raspberrypi-opensuse-20130907.img.xz
The exciting new thing is that this was created using an alternative image building automatism which I wrote from scratch in three hours this morning.
The scripts can be found at
https://build.opensuse.org/package/show/devel:ARM:Factory:Contrib:RaspberryPi/altimagebuild
and are also embedded within the image under /home/abuild/rpmbuild/SOURCES/
This means that everyone can now easily build his own images the way he likes and even branch and do submit requests for changes that are useful for others.
The way to use this is simple.
If you have 6GB RAM, you can speed things up with export OSC_BUILD_ROOT=/dev/shm/arm before you do
osc co devel:ARM:Factory:Contrib:RaspberryPi altimagebuild
cd devel:ARM:Factory:Contrib:RaspberryPi/altimagebuild
bash -x main.sh
This pseudo-package does not easily build within OBS or osc alone because it needs root permissions for some of the steps (chroot, mknod, mount), which could only be workarounded with User-Mode-Linux or patching osc.
The build consists of three steps that can be seen in main.sh:
This can build an image from scatch in three minutes. And my Raspberry Pi booted successfully with it within 55 seconds.
There are some remaining open issues:
Compared to the old image, this one has some advantages:
zypper install xauth twm xorg-x11-server xinit and start it with startx
So if you wanted to play with openSUSE on RPi, you can do so right now and have a lot of fun.
Michal Hrušecký has been helping out on maintaining Factory in shape and shares his experiences.
Factory is development version of openSUSE and it is where the next openSUSE is taking form. Hundreds of packagers send packages into Factory to be integrated as a part of the new release and many more use Factory for testing or for their daily work. Thus it is really important to keep Factory rolling and usable. Everybody knows that Coolo is the Factory master and he does everything to make next openSUSE be the best ever. But keeping factory in shape is really complicated and stressing task. There are dozens of request everyday and each one of them can potentially break something. So Factory can always use a pair of extra hands and for some time I have been one of them. I’d like to give you some insight in what we do, working on keeping Factory building and working. (more…)
Adrian Schröter (12)
Agustin Chavarria (6)
Alessandro de Oliveira Faria (13)
Alex Barrios (12)
Alexander Naumov (10)
Alexander Orlovskyy (3)
Alin M Elena (5)
Andrea Florio (27)
Andreas Jaeger (70)
Andreas Stieger (12)
Andrew Wafaa (31)
Arvin Schnell (9)
Atri Bhattacharya (3)
Bernhard Wiedemann (31)
Bonnie Kurniawan (1)
Bruno Friedmann (98)
Calumma Brevicorne (29)
Carl Fletcher (1)
Christopher Hobbs (17)
Ciaran Farrell (3)
Stephan Kulow (17)
craig gardner (2)
Stephan Barth (2)
Thomas Schmidt (2)
Dinar Valeev (1)
Dirk Mueller (2)
Dmitry Serpokryl (7)
Efstathios Iosifidis (21)
Fabio Mucciante (5)
Federico Lucifredi (9)
Greg Freemyer (1)
Holger Sickenberg (2)
Hubert Mantel (1)
Ilya Chernykh (5)
Ismail Donmez (1)
J. Daniel Schmidt (2)
James Tremblay (7)
Jan Blunck (4)
Jan Loeser (3)
Jan Madsen (1)
Jan-Christoph Bornschlegel (3)
Jan-Simon Möller (20)
Javier Llorente (12)
Jigish Gohil (85)
Jiri Srain (1)
Jiří Suchomel (3)
Johan Kotze (5)
José Oramas M. (6)
Josef Reidinger (16)
Juergen Weigert (1)
Julio Vannini (9)
Dinar Valeev (5)
Kevin "Yeaux" Dupuy (11)
Klaas Freitag (55)
Lars Vogdt (11)
Ludwig Nussel (13)
M. Edwin Zakaria (4)
Marcus Hüwe (39)
Marcus Meissner (2)
Marcus Moeller (3)
Marcus Schaefer (4)
Martin Lasarsch (8)
Martin Mohring (11)
Masim "Vavai" Sugianto (20)
Michael Andres (1)
Michael Löffler (7)
Michal Marek (7)
Michal Vyskocil (12)
Miguel Angel Barajas Hernandez (2)
P Linnell (2)
Nelson Marques (55)
Nenad Latinović (1)
Nikanth Karthikesan (2)
Przemyslaw Bojczuk (1)
Peter Pöml (4)
Petr Gajdos (2)
Petr Mladek (60)
Petr Uzel (5)
Ray Wang (1)
Raymond Wooninck (1)
Ricardo Chung (7)
Ricardo Varas Santana (7)
Richard Bos (11)
Robert Schweikert (16)
Rossana Motta (1)
Rupert Horstkötter (10)
Sascha Manns (66)
saydul akram (3)
Sebastian Siebert (6)
Shawn Dunn (2)
Stanislav Visnovsky (7)
Stefan Haas (1)
Stefan Hundhammer (5)
Stefan Schubert (7)
Steffen Winterfeldt (8)
Suresh Jayaraman (3)
Susanne Oberhauser (3)
Thomas Göttlicher (6)
Thomas Schraitle (26)
Togan Muftuoglu (3)
Tuukka Pasanen (36)
Will Stephenson (22)
YaST Team (90)