December 2013 - openSUSE Factory - openSUSE Mailing Lists

[opensuse-factory] One of the options for staging projects
by Michal Hrusecky 03 Dec '13

03 Dec '13

Hi, we are having a nice torrent of ideas in this mailing list since coolo presented this proposal last Thursday: https://progress.opensuse.org/workflow/factory-proposal.html Some of them are related to staging projects, so I will try to expand further one of the options regarding what could be happening inside that dashed box in the diagram. The main goal of staging projects is preventing Factory from breaking so often by creating a "temporary and alternative Factory" where dangerous and conflicting submissions have to learn to live in peace and harmony before entering the real Factory. The original mail from coolo contains a great example with new automake. So let's look closer into all those boxes, arrows and decision boxes: 1) Developer sends SR#1 to Factory and review team decides it needs staging, so staging project gets created (let's assume the decision is made by the review team, even if this is currently being discussed in the mailing list). The staging project initially contains only the package that is being sent and rebuilds everything from Factory that depend on it. 2) Stuff gets broken in staging, the submitter that sent SR#1 is now responsible for the project and in order to get SR#1 in Factory has to make sure staging project gets fixed. 2.1) The submitter fixes easy things that got broken. 2.2) The submitter coordinates with people who maintain packages that got broken. That means several people working on several packages (very often from different devel projects) all together to fix the new staging project. The fixes can be done in the devel projects or directly in the staging project. 2.2.a) Fixes in the devel projects gets into the staging project just by sending a SR to factory, more details below. 2.2.b) Every time a fix is done directly in the staging project it has to be sent back to the corresponding devel project. 3) When everything is fixed, stuff is merged in Factory and the staging project is deleted. See details below. Let's elaborate a little bit how 2.2.a works: - From one of the involved devel projects, SR#2 is sent to Factory fixing issues in staging project. - SR#2 gets grouped with SR#1 and the corresponding package in the staging project is replaced with link to the version in SR#2. New submissions replace the old ones. According to the procedure explained above, this is how 3 works: - When everything is fixed, there are in fact no local changes in the staging project except for things corresponding to the state of SRs in group. - Group will get accepted (all SR at the same time) and staging project deleted (as it is now merged into Factory). A last remark about the whole process: - if a package is involved in a staging project, submit requests to Factory that doesn't contain fix for the staging project are declined. It might be few exceptions like really dangerous zero day security exploit or data eating monster, but certainly not ordinary version bumps. This is just a proposal on how staging projects could work. The main goal of this proposal is to partially move the responsibility of the integration process into the community of packagers so: - Staging project maintainer has to cooperate with package maintainer to get his SR in. - Package maintainers have motivation to fix their stuff, otherwise new versions don't get included. The main advantages if this approach are: - Everything has to go through package maintainer to make sure changes don't get lost, package maintainers knows about the problems and agrees with the solution - We move from one good state to another, accepting only changes together with fixes. What do you think? What do you like/dislike? Opinions? -- Michal HRUSECKY SUSE LINUX, s.r.o. openSUSE Team Lihovarska 1060/12 PGP 0xFED656F6 19000 Praha 9 mhrusecky[at]suse.cz Czech Republic http://michal.hrusecky.net http://www.suse.cz -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

7 14

[opensuse-factory] OS 13.1 GA download?
by Thomas Taylor 02 Dec '13

02 Dec '13

When will the final GA DVD of OS 13.1 become available? When I go to the current milestone release site:http://software.opensuse.org/developer/en it is still showing RC2 as the current download. Thanks, Tom -- It is curious that physical courage should be so common in the world, and moral courage so rare. - Mark Twain ^^ --... ...-- / -.- --. --... -.-. ..-. -.-. ^^^^ Tom Taylor - retired penguin - KG7CFC AMD Phenom II x4 955 -- 4GB RAM -- 2x1.5TB sata2 openSUSE 13.1_RC2-x86_64 KDE 4.11.12, FF 24.0, claws-mail 3.9.2 registered linux user 263467 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

4 4

[opensuse-factory] wierd Mozilla deps
by Felix Miata 01 Dec '13

01 Dec '13

This is actually from 12.2, but it isn't the first time I've seen it happen, and could be happening with 13.1 or 12.3 too. (Ultimate object: get rid of forced tab aka further dumbed down Firefox, replacing it with FF17 and matching branding.) # zypper -v in firefox-esr-branding-upstream-17.0.10 Verbosity: 1 Non-option program arguments: 'firefox-esr-branding-upstream-17.0.10' Initializing Target Checking whether to refresh metadata for Mozilla Checking whether to refresh metadata for Non-OSS Checking whether to refresh metadata for OSS Checking whether to refresh metadata for Update-Non-Oss Checking whether to refresh metadata for Updates Loading repository data... Warning: Repository 'NonFreeUpdate' appears to outdated. Consider using a different mirror or server. Reading installed packages... Force resolution: No 'firefox-esr-branding-upstream-17.0.10' not found in package names. Trying 'firefox-esr-branding-upstream = 17.0.10'. Selecting 'firefox-esr-branding-upstream-17.0.10-2.1.i586' from repository 'Mozilla' for installation. Resolving package dependencies... Force resolution: No Problem: firefox-esr-branding-upstream-17.0.10-2.1.i586 conflicts with namespace:otherproviders(MozillaFirefox-branding) provided by MozillaFirefox-branding-upstream-25.0-2.63.1.i586 Solution 1: Following actions will be done: deinstallation of MozillaFirefox-branding-upstream-25.0-2.63.1.i586 deinstallation of MozillaFirefox-21.0-2.47.1.i586 Solution 2: do not install firefox-esr-branding-upstream-17.0.10-2.1.i586 Choose from above solutions by number or cancel [1/2/c] (c): 1 Applying solution 1 Resolving dependencies... Resolving package dependencies... Force resolution: No The following NEW packages are going to be installed: MozillaThunderbird 24.1.1-8.1 firefox-esr-branding-upstream 17.0.10-2.1 The following packages are going to be REMOVED: MozillaFirefox 21.0-2.47.1 MozillaFirefox-branding-upstream 25.0-2.63.1 2 new packages to install, 2 to remove. Overall download size: 22.6 MiB. After the operation, additional 7.8 MiB will be used. Continue? [y/n/?] (y): n # cat /pub/Tmp/out2 # zypper -v in firefox-esr-17.0.10 Verbosity: 1 Non-option program arguments: 'firefox-esr-17.0.10' Initializing Target Checking whether to refresh metadata for Mozilla Checking whether to refresh metadata for Non-OSS Checking whether to refresh metadata for OSS Checking whether to refresh metadata for Update-Non-Oss Checking whether to refresh metadata for Updates Loading repository data... Warning: Repository 'NonFreeUpdate' appears to outdated. Consider using a different mirror or server. Reading installed packages... Force resolution: No 'firefox-esr-17.0.10' not found in package names. Trying 'firefox-esr = 17.0.10'. Selecting 'firefox-esr-17.0.10-2.1.i586' from repository 'Mozilla' for installation. Resolving package dependencies... Force resolution: No Problem: firefox-esr-17.0.10-2.1.i586 conflicts with MozillaFirefox provided by MozillaFirefox-21.0-2.47.1.i586 Solution 1: Following actions will be done: deinstallation of MozillaFirefox-21.0-2.47.1.i586 deinstallation of MozillaFirefox-branding-upstream-25.0-2.63.1.i586 Solution 2: do not install firefox-esr-17.0.10-2.1.i586 Choose from above solutions by number or cancel [1/2/c] (c): 1 Applying solution 1 Resolving dependencies... Resolving package dependencies... Force resolution: No The following NEW packages are going to be installed: firefox-esr 17.0.10-2.1 firefox-esr-branding-upstream 24.1.0-2.1 The following packages are going to be REMOVED: MozillaFirefox 21.0-2.47.1 MozillaFirefox-branding-upstream 25.0-2.63.1 2 new packages to install, 2 to remove. Overall download size: 16.7 MiB. After the operation, 9.4 MiB will be freed. Continue? [y/n/?] (y): n There really shouldn't be any circumstance that causes TB to be touched in or out on account of theming or installing or deinstalling other Mozilla products. It seems to me zypper ought to be inclined to match versions of related products too, offering required branding at v17 to go with the v17 application. PS: speaking of wierd, why no opensuse-mozilla mailing list? Its lack makes picking a place to discuss a topic like this perplexing. -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

1 0

[opensuse-factory] syslog vs. journal
by Wolfgang Rosenauer 01 Dec '13

01 Dec '13

Hi, I'm wondering in which cases a syslog daemon is still required in 13.1 and beyond? On my new 13.1 system: Hygiea:~ # rpm -e rsyslog error: Failed dependencies: syslog is needed by (installed) syslog-service-2.0-772.1.2.noarch sysvinit(syslog) is needed by (installed) pcsc-lite-1.8.8-4.1.2.x86_64 sysvinit(syslog) is needed by (installed) cups-1.5.4-12.1.3.x86_64 So at least cups and pcsc-lite are explicitely requiring syslog and I wonder if that is still valid? Wolfgang -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

2 3

[opensuse-factory] Have php-pear-Net_IDNA2 in openSUSE:Factory
by Aeneas Jaißle 01 Dec '13

01 Dec '13

In an effort to push most packages currently in server:Kolab:Extras to openSUSE:Factory, I'd like to open a submit request from server:php:applications/php-pear-Net_IDNA2[1] to openSUSE:Factory/php-pear- Net_IDNA2. php-pear-Net_IDNA2 is a PHP library for Punycode encoding and decoding. It is required by roundcubemail, that is used as the default web client for Kolab. Any objections? [1] https://build.opensuse.org/package/show/server:php:applications/php5-pear-N… -- Aeneas Jaißle » e: aj(a)ajaissle.de Sent using Kontact and Kolab on openSUSE -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

2 2