August 2015 - openSUSE Features - openSUSE Mailing Lists

[New: openFATE 312810] Build a wireless lan access point
by fate_noreply＠suse.de 25 Aug '15

25 Aug '15

Feature added by: Juergen Weigert (jnweiger) Feature #312810, revision 1 Title: Build a wireless lan access point openSUSE.org: Unconfirmed Priority Requester: Important Requested by: Juergen Weigert (jnweiger) Partner organization: openSUSE.org Description: Use hostap mode to turn a laptop into a full featured access point. (not just ad-hoc). Find out which hardware is suitable. I have an USB-Wlan-dongle with rt73 chipset, whichis reported to support AP-mode. -- openSUSE Feature: https://features.opensuse.org/312810

1 3

[New: openFATE 319359] Wicked Internet Connection Tool
by fate_noreply＠suse.de 22 Aug '15

22 Aug '15

Feature added by: Norman Gorlt (norgo70) Feature #319359, revision 1 Title: Wicked Internet Connection Tool openFATE: Unconfirmed Priority Requester: Important Requested by: Norman Gorlt (norgo70) Partner organization: openSUSE.org Description: Up to openSUSE 13.1 we had the option to use ifup alternatively to Networkmanager. Internet connection via ifup was easy to use because we had smpppd and qinternet e.g. Now ifup is replaced by wicked and smpppd and qinternet aren't available anymore. For desktop computer with a fixed internet connection it's quite silly to use Networkmanager in my opinion. In this case wicked would be a good choice. But, unfortunately there don't exist a simple connection tool for easy useability. Connecting or disconnecting of internet connection via command line is not userfriendly. I would wish a simple icon in the taskbar similar we had in qinternet. Fist click onto icon establish the connection, 2nd click disconnect network connection. Maybe right click to show up/down load data rate. -- openSUSE Feature: https://features.opensuse.org/319359

1 1

[New: openFATE 319369] add Svdvorak to supported keyboard layouts
by fate_noreply＠suse.de 21 Aug '15

21 Aug '15

Feature added by: August Lindberg (aggelito) Feature #319369, revision 1 Title: add Svdvorak to supported keyboard layouts openSUSE Distribution: Unconfirmed Priority Requester: Desirable Requested by: August Lindberg (aggelito) Partner organization: openSUSE.org Description: Right now there are no alternatives for swedish dvorak layouts in the system keyboard layouts. Having the Svdvorak layout as a supported layout would be a nice addition. -- openSUSE Feature: https://features.opensuse.org/319369

1 1

[New: openFATE 314922] Amazon EC2
by fate_noreply＠suse.de 14 Aug '15

14 Aug '15

Feature added by: Paulo Andrade (bugsoftware) Feature #314922, revision 1 Title: Amazon EC2 SUSE Studio: Unconfirmed Priority Requester: Important Requested by: Paulo Andrade (bugsoftware) Partner organization: openSUSE.org Description: I would like Amazon EC2 support for Opensuse 12.3 -- openSUSE Feature: https://features.opensuse.org/314922

1 2

[New: openFATE 311401] Live CD templates
by fate_noreply＠suse.de 14 Aug '15

14 Aug '15

Feature added by: Mustafa Hadi (mustafa1987) Feature #311401, revision 1 Title: Live CD templates SUSE Studio: Unconfirmed Priority Requester: Desirable Requested by: Mustafa Hadi (mustafa1987) Partner organization: openSUSE.org Description: Add a template with their default package selection is all the software available on the live CDs (KDE Live CD and Gnome Live CD) and the software automatically selected on the first yast software manager run, adding these templates is not hard to do (they are just package selection lists) an its benifits will be great. Business case (Partner benefit): openSUSE.org: To provide a complete operating system that can be then extended with additional software, the KDE4 template is just not enough. -- openSUSE Feature: https://features.opensuse.org/311401

1 3

[openFATE 305015] support noarch via own scheduler in Build Service
by fate_noreply＠suse.de 14 Aug '15

14 Aug '15

Feature changed by: Adrian Schröter (adrianSuSE) Feature #305015, revision 13 Title: support noarch via own scheduler in Build Service Buildservice: Evaluation by engineering manager Priority Requester: Desirable Projectmanager: Desirable Requested by: Adrian Schröter (adriansuse) Requested by: Lars Vogdt (lrupp) Partner organization: openSUSE.org Description: We would like to build noarch packages only once to avoid multiple builds and wasted space on the server. This can be reached by building noarch packages only via an dedicated scheduler. However, we need to avoid that have a horrible project configuration, where all BuildRequired noarch packages needs to get submitted into all other architecture repository :full trees. + The biggest problem is that build cycle detection is not working + accross schedulers. We would have endless builds easily with the + current code. Discussion: #1: Adrian Schröter (adriansuse) (2010-02-19 10:48:58) Theoretically already possible, still questionable if we want this. -> keep it in evaluation #2: Greg Freemyer (gregfreemyer) (2012-03-30 20:14:05) I can think of of at least 3 ways to accomplish the goal: 1) Allow noarch builds of just one arch to be accepted to factory. Then encourage people to just enable one arch. Hopefully randomly to spread the load around. 2) Create a new "noarch" architecture and scheduler. Have that feed whatever actual scheduler has the lightest load at schedule time. That way even non-Intel machines could build the noarch packages. 3) Enforce in all schedulers but one, that they ignore noarch packages. Then document that so everyone knows they can only build noarch on i586 (as an example). idea 1) seems relatively doable for a modest effort. idea 2) would require changes lots of places I assume, so it is not trivial. idea 3) seems like the least work by far, and it sheds work load from one of the schedulers. I don't know if that would benefit the overall OBS load or not. And I'm sure there are other ways. === The question is if the wasted build resources is worth the R&D to bother with fixing this. #3: Claudio Freire (klaussfreire) (2012-03-30 20:30:05) (reply to #2) 3) Enforce in all schedulers but one, that they ignore noarch packages. Then document that so everyone knows they can only build noarch on i586 (as an example). I think this is the best option. For one, making sure noarch packages are built in the same architecture every time will help avoid spurious deltas: if a package builds differently on different architectures, but the packager decided that the difference is inconsequential. For instance, arm zlib needs not produce the same output as x86 zlib. For two, i586 and x86_64, AFAIK, use the same hosts. Right? So spreading the load among those two is useless. But there are quite a few caveats. One, people should not care about which arch is enabled, if there is any enabled archs for a noarch package, it should be built by "the noarch" scheduler (say, the x86_64 scheduler). If there are many archs enabled, only one build should be scheduled, and build results should be replicated. This might need some doing. 2) Create a new "noarch" architecture and scheduler. Have that feed whatever actual scheduler has the lightest load at schedule time. That way even non-Intel machines could build the noarch packages. So, more to-the-point would be option 2, but it still doesn't completely convince me, because it would be quite confusing in the UI. There also option 1, which I guess would work for factory (but not other projects). It's already common practice in OBS to only enable one arch for big noarch packages, so it should be rather easy to do - just fix factory-auto's validation script to account for noarch packages. About the benefits, I have a few projects that build hundred-MB noarch rpms with game data. Those take a lot of I/O resources to build, so the inefficiency (in that case) is significant. I'm not sure about how many projects are found in that situation, though. I would vote to get option 1 implemented ASAP - it should be easy and immediate. If I wanted to patch it... where should I go to find the factory-auto script? #5: Jan Engelhardt (jengelh) (2015-08-14 00:06:13) (reply to #2) >[3.] Then document that so everyone knows they can only build noarch on i586 And if you have no x86? Like, a PPC-only pool. Suggestion [2] doing a round-robin seems preferable. #4: Stefan Brüns (stefanbruens) (2015-07-20 17:10:51) I think this should be reevaluated - ARM builds are really slow, and e. g kernel-docs takes a full day to rebuild. -- openSUSE Feature: https://features.opensuse.org/305015

1 0

[openFATE 305015] support noarch via own scheduler in Build Service
by fate_noreply＠suse.de 13 Aug '15

13 Aug '15

Feature changed by: Jan Engelhardt (jengelh) Feature #305015, revision 12 Title: support noarch via own scheduler in Build Service Buildservice: Evaluation by engineering manager Priority Requester: Desirable Projectmanager: Desirable Requested by: Adrian Schröter (adriansuse) Requested by: Lars Vogdt (lrupp) Partner organization: openSUSE.org Description: We would like to build noarch packages only once to avoid multiple builds and wasted space on the server. This can be reached by building noarch packages only via an dedicated scheduler. However, we need to avoid that have a horrible project configuration, where all BuildRequired noarch packages needs to get submitted into all other architecture repository :full trees. Discussion: #1: Adrian Schröter (adriansuse) (2010-02-19 10:48:58) Theoretically already possible, still questionable if we want this. -> keep it in evaluation #2: Greg Freemyer (gregfreemyer) (2012-03-30 20:14:05) I can think of of at least 3 ways to accomplish the goal: 1) Allow noarch builds of just one arch to be accepted to factory. Then encourage people to just enable one arch. Hopefully randomly to spread the load around. 2) Create a new "noarch" architecture and scheduler. Have that feed whatever actual scheduler has the lightest load at schedule time. That way even non-Intel machines could build the noarch packages. 3) Enforce in all schedulers but one, that they ignore noarch packages. Then document that so everyone knows they can only build noarch on i586 (as an example). idea 1) seems relatively doable for a modest effort. idea 2) would require changes lots of places I assume, so it is not trivial. idea 3) seems like the least work by far, and it sheds work load from one of the schedulers. I don't know if that would benefit the overall OBS load or not. And I'm sure there are other ways. === The question is if the wasted build resources is worth the R&D to bother with fixing this. #3: Claudio Freire (klaussfreire) (2012-03-30 20:30:05) (reply to #2) 3) Enforce in all schedulers but one, that they ignore noarch packages. Then document that so everyone knows they can only build noarch on i586 (as an example). I think this is the best option. For one, making sure noarch packages are built in the same architecture every time will help avoid spurious deltas: if a package builds differently on different architectures, but the packager decided that the difference is inconsequential. For instance, arm zlib needs not produce the same output as x86 zlib. For two, i586 and x86_64, AFAIK, use the same hosts. Right? So spreading the load among those two is useless. But there are quite a few caveats. One, people should not care about which arch is enabled, if there is any enabled archs for a noarch package, it should be built by "the noarch" scheduler (say, the x86_64 scheduler). If there are many archs enabled, only one build should be scheduled, and build results should be replicated. This might need some doing. 2) Create a new "noarch" architecture and scheduler. Have that feed whatever actual scheduler has the lightest load at schedule time. That way even non-Intel machines could build the noarch packages. So, more to-the-point would be option 2, but it still doesn't completely convince me, because it would be quite confusing in the UI. There also option 1, which I guess would work for factory (but not other projects). It's already common practice in OBS to only enable one arch for big noarch packages, so it should be rather easy to do - just fix factory-auto's validation script to account for noarch packages. About the benefits, I have a few projects that build hundred-MB noarch rpms with game data. Those take a lot of I/O resources to build, so the inefficiency (in that case) is significant. I'm not sure about how many projects are found in that situation, though. I would vote to get option 1 implemented ASAP - it should be easy and immediate. If I wanted to patch it... where should I go to find the factory-auto script? + #5: Jan Engelhardt (jengelh) (2015-08-14 00:06:13) (reply to #2) + >[3.] Then document that so everyone knows they can only build noarch + on i586 And if you have no x86? Like, a PPC-only pool. + Suggestion [2] doing a round-robin seems preferable. #4: Stefan Brüns (stefanbruens) (2015-07-20 17:10:51) I think this should be reevaluated - ARM builds are really slow, and e. g kernel-docs takes a full day to rebuild. -- openSUSE Feature: https://features.opensuse.org/305015

1 0

[New: openFATE 318204] Drop Yast LXC (replaced by libvirt / docker)
by fate_noreply＠suse.de 05 Aug '15

05 Aug '15

Feature added by: Lukas Ocilka (locilka) Feature #318204, revision 1 Title: Drop Yast LXC (replaced by libvirt / docker) Requested by: Lukas Ocilka (locilka) Partner organization: openSUSE.org Description: Yast LXC is not needed anymore, libvirt-lxc already covers that. Additionally, docker with Yast Docker module seem to be a good replacement for LXC. Business case (Partner benefit): openSUSE.org: Less code to maintain, less bugs. Yast doesn't need to provide functionality that already exists and is maintained elsewhere. -- openSUSE Feature: https://features.opensuse.org/318204

1 6

[New: openFATE 319299] require libvirt-images subvolume creation at install time
by fate_noreply＠suse.de 03 Aug '15

03 Aug '15

Feature added by: Chris Murphy (cmurf) Feature #319299, revision 1 Title: require libvirt-images subvolume creation at install time Requested by: Chris Murphy (cmurf) Partner organization: openSUSE.org Description: Similar to https://features.opensuse.org/319287 Create a subvolume in the top level of the file system for libvirt images, and add it to fstab to mount at /var/lib/libvirt/images/ Without this, any rollback will be missing virt-manager VM images. -- openSUSE Feature: https://features.opensuse.org/319299

1 4