Bug 6352 - Epoch 1 for ogmtools in Mageia 1, Epoch 0 in Mageia 2 => upgrade impossible
Summary: Epoch 1 for ogmtools in Mageia 1, Epoch 0 in Mageia 2 => upgrade impossible
Status: RESOLVED FIXED
Alias: None
Product: Mageia
Classification: Unclassified
Component: RPM Packages (show other bugs)
Version: 2
Hardware: All Linux
Priority: Normal major
Target Milestone: ---
Assignee: QA Team
QA Contact:
URL:
Whiteboard:
Keywords: validated_update
Depends on:
Blocks:
 
Reported: 2012-06-06 18:12 CEST by Samuel Verschelde
Modified: 2012-06-27 16:42 CEST (History)
3 users (show)

See Also:
Source RPM:
CVE:
Status comment:


Attachments

Description Samuel Verschelde 2012-06-06 18:12:37 CEST
Description of problem:

Epoch for ogmtools was removed from Mageia Cauldron a few months ago, but the package submitted to Mageia 1 had an epoch value of 1, and it wasn't noticed before Mageia 2 was released.

An update to Mageia 2 should increase the Epoch for this package.

See http://mageia.madb.org/package/comparison/release/1/withrelease/2/application/0/source/1/t_search/ogmtools
Samuel Verschelde 2012-06-06 18:13:12 CEST

Assignee: bugsquad => oliver.bgr

Comment 1 Oliver Burger 2012-06-14 10:54:54 CEST
On import into Mga the Epoch was removed but it was added again to ease upgrade from Mdv2010.1/.2
The current package does have an Epoch value of 1, so I don't understand the bugreport.
See http://svnweb.mageia.org/packages/updates/2/ogmtools/current/SPECS/ogmtools.spec
and http://svnweb.mageia.org/packages/cauldron/ogmtools/current/SPECS/ogmtools.spec
Comment 2 Samuel Verschelde 2012-06-14 11:02:46 CEST
svn is ok, but packages are not, maybe you forgot to submit, or more likely the build system didn't like a submit where version and release didn't change:

[sam@localhost ~]$ rpm -qp ogmtools-1.5-7.mga2.i586.rpm --qf '%{EPOCH}\n'
(none)
[sam@localhost ~]$ rpm -qp ogmtools-1.5-7.mga1.i586.rpm --qf '%{EPOCH}\n'
1
Comment 3 Oliver Burger 2012-06-14 11:16:33 CEST
Pushed for 2 and Cauldron.

---
This update fixes the missing epoch tag in 2 and cauldron, that is needed for updating the package from Mga1
---

CC: (none) => oliver.bgr
Assignee: oliver.bgr => qa-bugs

Comment 4 claire robinson 2012-06-19 13:00:26 CEST
Testing x86_64

Before
------
# urpmi ogmtools

# rpm -q ogmtools
ogmtools-1.5-7.mga2

# rpm -q ogmtools --qf '%{EPOCH}\n'
(none)


After
-----
# rpm -q ogmtools --qf '%{EPOCH}\n'
1

# rpm -q ogmtools
ogmtools-1.5-7.1.mga2

$ urpmf --media "Core Updates Testing" ogmtools | grep bin
ogmtools:/usr/bin/dvdxchap
ogmtools:/usr/bin/ogmcat
ogmtools:/usr/bin/ogmdemux
ogmtools:/usr/bin/ogminfo
ogmtools:/usr/bin/ogmmerge
ogmtools:/usr/bin/ogmsplit

$ ogminfo big_buck_bunny_480p_stereo.ogg 
(ogminfo.c) OGG stream 1 is of an unknown type (bad header?)
(ogminfo.c) (a1/serial 531112804) Vorbis audio (channels 2 rate 48000)

Wrong kind of ogg.

Encoded an avi to ogm with avidemux, just using copy for video and audio and ogm container.

$ ogminfo sample.ogm
(ogminfo.c) (v1/serial 1) fps: 24.000 width height: 854x480 codec: 0x464d5034 (FMP4)
(ogminfo.c) (a1/serial 2) codec: 8192 (0x2000) (AC3) bits per sample: 2 channels: 6  samples per second: 48000 avgbytespersec: 56000 blockalign: 1536

$ du -h sample.ogm
212M    sample.ogm

$ ogmsplit -s 100 sample.ogm
(ogmsplit.cpp) First pass: finding split points. This may take a while. Get something to drink.
FATAL: could not allocate -1984626431 bytes of memory.

May be a problem with ogmsplit.

$ ogmdemux sample.ogm

$ ls sample*
sample.ogm  sample.ogm-a1.ac3  sample.ogm-v1.avi

$ ogmmerge -o sample2.ogm sample.ogm-a1.ac3 sample.ogm-v1.avi 
Using AC3 demultiplexer for sample.ogm-a1.ac3.
+-> Using AC3 output module for audio stream.
Using AVI demultiplexer for sample.ogm-v1.avi. Opening file. This may take some time depending on the file's size.
+-> Using video output module for video stream.
progress: 14314/14314 frames (100%)

$ ls sample*
sample2.ogm  sample.ogm  sample.ogm-a1.ac3  sample.ogm-v1.avi

All seems fine apart from ogmsplit but having checked, that is not a regression. It could be something to do with the sample I am using.

Testing complete x86_64
Comment 5 claire robinson 2012-06-19 13:12:46 CEST
Bug 6509 created for buggy ogmsplit, do you want to look into this now Oliver?
Comment 6 Oliver Burger 2012-06-19 13:16:25 CEST
Let's push this update first if it's not a regression. I will look into the other thing later.
Comment 7 claire robinson 2012-06-22 13:38:05 CEST
i586

# dcupdt
Disabling Core Updates Testing

# urpmi ogmtools
A requested package cannot be installed:
ogmtools-1.5-7.mga2.i586 (in order to keep ogmtools-1.5-7.mga1.i586)
Continue installation anyway? (Y/n) n

# rpm -q ogmtools --qf '%{EPOCH}\n'
1

# ecupdt
Enabling Core Updates Testing

# urpmi ogmtools

installing ogmtools-1.5-7.1.mga2.i586.rpm from /var/cache/urpmi/rpms             
Preparing...                     ###############################################
      1/1: ogmtools              ###############################################

# rpm -q ogmtools --qf '%{EPOCH}\n'
1

Testing complete i586
Comment 8 claire robinson 2012-06-22 13:40:19 CEST
Validating

Advisory
-------------
This is a minor update for ogmtools which just increases the epoch to enable upgrade from Mageia 1
-------------

SRPM: ogmtools-1.5-7.1.mga2.src.rpm


Could sysadmin please push from core/updates_testing to core/updates

Thanks!

Keywords: (none) => validated_update
CC: (none) => sysadmin-bugs
Hardware: i586 => All

Comment 9 Thomas Backlund 2012-06-27 16:42:54 CEST
Update pushed:
https://wiki.mageia.org/en/Support/Advisories/MGAA-2012-0088

Status: NEW => RESOLVED
CC: (none) => tmb
Resolution: (none) => FIXED


Note You need to log in before you can comment on or make changes to this bug.