openSUSE Project Management Tool: Issueshttps://progress.opensuse.org/https://progress.opensuse.org/themes/openSUSE/favicon/favicon.ico?15829177842015-09-10T10:54:31ZopenSUSE Project Management Tool
Redmine openSUSE Leap 42.1 Release - action #8722 (Resolved): sync the release to the mirrorshttps://progress.opensuse.org/issues/87222015-09-10T10:54:31Zdimstardimstar@opensuse.org
<p>follow instructions in Sync-Opensuse.txt</p>
openSUSE Leap 42.1 Release - action #8718 (Closed): find external BT seedershttps://progress.opensuse.org/issues/87182015-09-10T10:54:28Zdimstardimstar@opensuse.org
<p>put torrent in separate directories, ask for volunteers to seed => darix</p>
<p>Torrents are created using /work/cd/bin/torrent-wrapper.pl</p>
openSUSE Leap 42.1 Release - action #8716 (Closed): remind opensuse.org admins of releasehttps://progress.opensuse.org/issues/87162015-09-10T10:54:27Zdimstardimstar@opensuse.org
<p>remind opensuse.org admins about the upcoming release and to verify that the HA proxy can handle the load</p>
openSUSE Leap 42.1 Release - action #8714 (Resolved): marketing brainstorm sessionhttps://progress.opensuse.org/issues/87142015-09-10T10:54:25Zdimstardimstar@opensuse.org
<p>create a hangout with all the marketing guys to come up with creative things how to promote the release (to find ideas like the green smoke thing on 12.3)</p>
openSUSE Leap 42.1 Release - action #8712 (Closed): communicate GM issues to marketinghttps://progress.opensuse.org/issues/87122015-09-10T10:54:24Zdimstardimstar@opensuse.org
<p>If there are any known issues in GM marketing needs to know about them to decide how to communicate them</p>
openSUSE Leap 42.1 Release - action #8710 (Closed): publish docuhttps://progress.opensuse.org/issues/87102015-09-10T10:54:22Zdimstardimstar@opensuse.org
<p>doc.opensuse.org<br>
<a href="https://en.opensuse.org/SDB:Official_documentation" class="external">https://en.opensuse.org/SDB:Official_documentation</a></p>
<p>Ping Frank Sundermeyer about it</p>
openSUSE Leap 42.1 Release - action #8708 (Closed): call for translationhttps://progress.opensuse.org/issues/87082015-09-10T10:51:20Zdimstardimstar@opensuse.org
<p>The most important languages in the distro, esp those on the DVD need to be translated. Remind translation teams.</p>
<p><a href="http://i18n.opensuse.org/stats/trunk/toplist.php" class="external">http://i18n.opensuse.org/stats/trunk/toplist.php</a></p>
Staging project workflow - action #8498 (Resolved): Leap 42: update crawler replaces SP1 packages...https://progress.opensuse.org/issues/84982015-08-13T15:36:04Zdimstardimstar@opensuse.org
<p>Leap 42.1 has moved on, in some areas at least, to track packages from SLE12 SP1.</p>
<p>Running update-crawler currently tries to revert those packages back to the ones in SUSE:SLE-12:Update, which is not what we want.<br>
At this moment, there are no patches published for SP1 yet.</p>
<p>As there are still new patches landing in GA:Update, crawler is still a worthwile addition, but it should not touch packages that are currently linked to the SP1 branch</p>
openQA Project - action #7442 (Resolved): Cloning a job can lose job settingshttps://progress.opensuse.org/issues/74422015-05-09T08:33:18Zdimstardimstar@opensuse.org
<p>The job <a href="https://openqa.opensuse.org/tests/61594" class="external">https://openqa.opensuse.org/tests/61594</a> does not have the variable LIVETEST set to 1, which results in the test failing</p>
<p>This job was cloned from <a href="https://openqa.opensuse.org/tests/61517" class="external">https://openqa.opensuse.org/tests/61517</a> which had the variable set. So the cloning of a job seems to be able to lose variables on the way.</p>
openQA Project - action #6784 (Resolved): Test marked 'failed' without apparent reasonhttps://progress.opensuse.org/issues/67842015-03-19T13:04:23Zdimstardimstar@opensuse.org
<p>This is something I have seen more often lately, but surprisingly only on the rescuesystem tests (maybe because it's so short-living?)</p>
<p>A sample run:<br>
<a href="https://openqa.opensuse.org/tests/52724" class="external">https://openqa.opensuse.org/tests/52724</a></p>
<p>The step "rescuesystem_validate_131" has no return value; in autoinst-log.txt, it is visible that the awaited serial string has been seen (can also be confirmed in serial.txt)</p>
<p>The end of the log:<br>
`Debug: /var/lib/openqa/share/tests/opensuse/tests/installation/rescuesystem_validate_131.pm:10 called testapi::type_string<br>
<<< type_string(string=$VAR1 = '\'cat /mnt/etc/SUSE-brand > /dev/ttyS0<br>
\'';<br>
, max_interval=$VAR1 = '\'250\'';<br>
)<br>
Debug: /var/lib/openqa/share/tests/opensuse/tests/installation/rescuesystem_validate_131.pm:11 called testapi::wait_serial<br>
<<< wait_serial(regex=$VAR1 = 'VERSION = 13.1';<br>
, timeout=$VAR1 = 2;<br>
)</p>
<blockquote>
<blockquote>
<blockquote>
<p>wait_serial: VERSION = 13.1: ok<br>
||| finished rescuesystem_validate_131 installation at 2015-03-18 23:12:39 (6 s)<br>
isotovideo done<br>
waitpid for 15800 returned 0<br>
sending TERM to qemu pid: 15800<br>
waitpid for 15800 returned 15800<br>
QEMU: qemu: terminating on signal 15 from pid 15757<br>
sending magic and exit<br>
received magic close<br>
killing commands thread<br>
done joining commands thread<br>
+++ worker notes +++<br>
end time: 2015-03-18 23:12:52<br>
result: done`</p>
</blockquote>
</blockquote>
</blockquote>
Staging project workflow - action #6406 (Resolved): staging locks: stepping on ones own foothttps://progress.opensuse.org/issues/64062015-02-24T17:16:34Zdimstardimstar@opensuse.org
<p>Currently, osc staging sets a lock on a user, which is fine (avoiding a 2nd user to mess up)</p>
<p>Consider this though (all done as one user)</p>
<ul>
<li>osc staging freeze A (this is a lengthy task, usually about 3 - 5 minutes)</li>
<li>In the same time, the same user who has the lock opens a new term and issues
osc staging list</li>
</ul>
<p>The 2nd call is permitted (the lock is owned by the user, so accepted to continue). yet, once the 2nd call terminates, the lock is being removed, despite task 1 still being ative.</p>
<p>Two options:</p>
<ul>
<li>Either disallow the ame user from running two commands in parallel (we can live with that)</li>
<li>Ensure that a 2nd command can't remove the first commands lock (adding a refcount?)</li>
</ul>
Staging project workflow - action #6380 (Resolved): staging accept: checking for new .spec files ...https://progress.opensuse.org/issues/63802015-02-23T12:28:05Zdimstardimstar@opensuse.org
<p>It seems the latest rewrite of the configuration changed the meaning of self.api.project when accepting packages (or it never worked, which is hard to believe.</p>
<p>We have this code:<br>
for req in rqlist:<br>
oldspecs = self.api.get_filelist_for_package(pkgname=req['packages'][0], project=self.api.project, extension='spec')<br>
print 'Accepting request %d: %s' % (req['id'], ','.join(req['packages']))<br>
change_request_state(self.api.apiurl, str(req['id']), 'accepted', message='Accept to %s' % self.api.project)<br>
# Check if all .spec files of the package we just accepted has a package container to build<br>
self.create_new_links(self.api.project, req['packages'][0], oldspecs)<br>
changed = True</p>
<p>self.api.project USED to point to openSUSE:Factory (so we get the file list, accept the package, get the file list of the now checked in package and compare).</p>
<p>Currently, self.api.project seems to be pointing to the Staging project a package is coming from (no longer the target).</p>
Staging project workflow - action #6258 (Rejected): repo-checker: need a way to accept new edgeshttps://progress.opensuse.org/issues/62582015-02-12T09:05:41Zdimstardimstar@opensuse.org
<p>Currently, the repo checker detects new cycles and adds new reviews, with no way for the factory maintainers to consciously accept those new cycles.</p>
<p>We need to come up with a solution to be able to accept those new cycles (current Staging:B)</p>
Staging project workflow - action #5904 (New): repo-checker needs to check for duplicate binary p...https://progress.opensuse.org/issues/59042015-01-16T10:03:26Zdimstardimstar@opensuse.org
<p>Real case scenario:</p>
<p>digikam (source package) produces multiple binary packages, of which at least: digikam, libkface3<br>
a new source package libkface was submitted to Factory, which produced a binary package libkface3 (generally the same library, different version).</p>
<p>repo-checker should raise duplicate source package names as issue, as there is no guarantee on the results of which is going to be used in the end.</p>
openQA Project - action #5420 (Resolved): openQA considers previously 'failed' tests now as 'inco...https://progress.opensuse.org/issues/54202014-12-09T13:05:36Zdimstardimstar@opensuse.org
<p><a href="https://openqa.opensuse.org/tests/38422" class="external">https://openqa.opensuse.org/tests/38422</a> is a sample test - it appears to be 'failed' to the user (and was consdiered failed until the re-deployment of openQA on Dec 9).</p>
<p>Since this upgrade, it is now considered 'incomplete'</p>