Bug 2868 - mgarepo sync doesn't pick up changed binary files
Summary: mgarepo sync doesn't pick up changed binary files
Status: RESOLVED FIXED
Alias: None
Product: Mageia
Classification: Unclassified
Component: RPM Packages (show other bugs)
Version: Cauldron
Hardware: All Linux
Priority: Normal normal
Target Milestone: ---
Assignee: papoteur
QA Contact:
URL:
Whiteboard: Mga4too
Keywords:
Depends on:
Blocks:
 
Reported: 2011-09-29 09:01 CEST by Florian Hubold
Modified: 2023-04-07 11:53 CEST (History)
4 users (show)

See Also:
Source RPM: mgarepo-1.10.0-2.mga1.src.rpm
CVE:
Status comment:


Attachments

Description Florian Hubold 2011-09-29 09:01:28 CEST
Description of problem:

During updating of mozilla-thunderbird-l10n i discovered this problem. I overwrote all 50 .xpi files (they're contained in binrepos) which had all changed contents. But mgarepo sync didn't pick up those. I had to "mgarepo upload SOURCES/*.xpi"

Please fix.
Remco Rijnders 2011-09-29 09:11:07 CEST

Assignee: bugsquad => boklm

Comment 1 Florian Hubold 2011-11-01 14:44:45 CET
Ping?
Comment 2 Nicolas Vigier 2011-11-01 14:53:39 CET
Nobody provided a patch.
Comment 3 Marja Van Waes 2012-02-09 17:04:32 CET
Pinging, because nothing has happened with this report for more than 3 months, it still has the status NEW or REOPENED.

a patch is welcome :)

CC: (none) => marja11

Nicolas Vigier 2012-02-09 17:10:08 CET

Status: NEW => ASSIGNED

Comment 4 Manuel Hiebel 2012-10-20 22:03:59 CEST
boklm leave Mageia

Assignee: boklm => bugsquad
Status: ASSIGNED => NEW

Comment 5 Manuel Hiebel 2012-11-05 16:52:54 CET
This message is a reminder that Mageia 1 is nearing its end of life. 
In approximately 25 days from now, Mageia will stop maintaining and issuing 
updates for Mageia 1. At that time this bug will be closed as WONTFIX (EOL) if it 
remains open with a Mageia 'version' of '1'.

Package Maintainer: If you wish for this bug to remain open because you plan to 
fix it in a currently maintained version, simply change the 'version' to a later 
Mageia version prior to Mageia 1's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that we may not 
be able to fix it before Mageia 1 is end of life.  If you would still like to see 
this bug fixed and are able to reproduce it against a later version of Mageia, 
you are encouraged to click on "Version" and change it against that version 
of Mageia.

Although we aim to fix as many bugs as possible during every release's lifetime, 
sometimes those efforts are overtaken by events. Often a more recent Mageia 
release includes newer upstream software that fixes bugs or makes them obsolete.

--
Mageia Bugsquad
Comment 6 Manuel Hiebel 2012-12-02 14:32:21 CET
Mageia 1 changed to end-of-life (EOL) status on ''1st December''. Mageia 1 is no 
longer maintained, which means that it will not receive any further security or 
bug fix updates. As a result we are closing this bug. 

If you can reproduce this bug against a currently maintained version of Mageia 
please feel free to click on "Version" change it against that version of Mageia and reopen this bug.

Thank you for reporting this bug and we are sorry it could not be fixed.

--
Mageia Bugsquad

Resolution: (none) => WONTFIX
Status: NEW => RESOLVED

Comment 7 Florian Hubold 2014-09-09 00:29:14 CEST
This is still present and valid, please don't close it. Sorry, but "nobody provided a patch" was the only answer until now, which does not fix the issue.

Resolution: WONTFIX => (none)
Status: RESOLVED => REOPENED
CC: (none) => doktor5000
Version: 1 => 4

Manuel Hiebel 2014-09-09 00:40:34 CEST

Whiteboard: (none) => Mga4too
Version: 4 => Cauldron

Comment 8 Rémi Verschelde 2014-09-09 12:32:58 CEST
Apart from "mgarepo upload"ing all source files, the only workaround that I know of is to remove the changed files from the sha1.lst.

CC: (none) => remi

Comment 9 Florian Hubold 2014-09-09 22:31:15 CEST
(In reply to Rémi Verschelde from comment #8)
> the only workaround that I
> know of is to remove the changed files from the sha1.lst.

Do you really expect me to create checksums for all source files, and manually compare them to sha1.lst and remove offending ones? That is exactly the purpose that mgarepo should fulfill, no?
Comment 10 Rémi Verschelde 2014-09-09 22:37:17 CEST
> (In reply to Rémi Verschelde from comment #8)
> > the only workaround that I
> > know of is to remove the changed files from the sha1.lst.
> 
> Do you really expect me to create checksums for all source files, and
> manually compare them to sha1.lst and remove offending ones? That is exactly
> the purpose that mgarepo should fulfill, no?

Nope, I just considered that you knew which files changed (since comment 0 says "they had all changed contents"), and in such case you just have to remove all of them from sha1.lst to force their upload.

And I said "workaround", of course I'd like mgarepo sync to do the sync in a better way, checking for sha1 sums and uploading the changed files. But since I won't provide a patch for mgarepo myself, I'm sharing my workaround.
Comment 11 Marja Van Waes 2016-08-01 11:15:37 CEST
Assuming this bug is still valid, I didn't find anything in the git & svn logs that suggests it got fixed (but may have overlooked it).

@ papoteur

Feel free to re-assign if you don't want to be the assignee ;-)

Assignee: bugsquad => yves.brungard_mageia

Comment 12 Dan Fandrich 2023-04-07 11:53:21 CEST
I've implemented this feature in mgarepo. It's activated with the -u or --upload option. The next release of mgarepo will include it.

Status: REOPENED => RESOLVED
CC: (none) => dan
Resolution: (none) => FIXED


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