Le dimanche 21 février 2016, 18:13:32 Markus Koschany a écrit :
> Am 21.02.2016 um 16:40 schrieb Phil Morrell:
> > Hi all, I'd like to help out with packaging tasks, but I'm a lurker by
> > habit, so I thought I'd post my partial actions so far and hope for
> > some advice on next steps/debian etiquette. Please feel free to answer
> > just a part of my email, that would be very useful in making progress
> > in even one area as I'm a bit frustrated.
> [...]
>
> Hi,
>
> don't hesitate to commit updates, improvements, new upstream releases
> and patches. If you think you can provide a fix for a bug, just do it
> and push your changes and ask for review and sponsorship on this list.
I agree. If it's the one obvious thing to do, just do it.
> > I realise that's also too small an issue to trigger a new version
> > upload, so will it just remain action needed forever? Would it still
> > be best to make the change in SVN anyway, so if a larger issue did
> > come up, this minor thing would be automatically fixed for the
> > maintainer?
For exemple, I was doing test builds of to-be scummvm 1.8.0;
I thought that the 3-lines changelog I had written could
spare some work to others, so I just pushed it.
If that was SVN, er... maybe not, I haven't used
this thing in so many years.
>> corsix-th 0.50: This is where I started, it's still in the new queue,
>> but I run Jessie so I backported and built it with gbp, needed to
>> change dependencies to use ffmpeg rather than libav, committed and
>> pushed to branch - success!
Current packaging is a merger of the original Debian attempt
+ ideas from GetDeb & other distro's; feel free to improve it further.
With a slow release cycle, this one shouldn't require many upload.
>>game-data-packager 44: I needed to install the media, but version in
>>Jessie is just older than the massive refactor with heavy development
>>in the last year, so again backported it locally. After downloading
>>from GOG.com, I had a 2.1.0.8.exe, but g-d-p expected v2.0.0.5
- so two things:
adding this + size + md5 + sha1:
setup_theme_hospital_2.1.0.8.exe:
unpack:
format: innoextract
provides:
- full game
- levels/full00.sam?gog
- manual.pdf
>> simply replace the 2.0.0.5 lines
please no, most of the times what changes from one version to another is the addvertisements in /tmp;
or maybe dosbox.conf or other things that aren't needed by corsix-th;
so the 2.0.0.5 archive remain perfectly valid for use with GDP
>> is that even a contribution the project welcomes given that
>> once you have the deb, you're unlikely to need to re-download the exe?
It's for helping the other future users; I guess most people working on G-D-P
don't even really _need_ it. But they may prefer writing a .yaml file than an extra-long
readme.Debian that list N steps to do for the contrib engine they are working on.
Another thing:
- if the file come fresh from lgogdownloader or if the md5 is listed in lgogdownloader's cache;
it will be trusted.
Other InnoSetup archives are not trusted by default.
Maybe could InnoExtract be extensively reviewed and considered trusted at some point;
like .zip & .tar.* already are ?
>> lgogdownloader:
This thing depends on a web scrapper, so like Youtube-DL it's doomed to break all the time.
Most interrested users are using Arch AUR-git repository;
so it basically seemed to be rebuilt on every commit (?),
don't mind asking upstream a release if you feel it's needed.
>>game-data-packager:
>>* lintian - dep5-copyright-license-name-not-unique line
seems like a false positive, you can dig in lintian's code...
>> 798816
It's about repacking the .ogg soundtracks provided by ogg.
What I have now here is quake-music-gog extra package that provides virtual package "quake-music".
The Python code needs more work to abstract that out. ("audio tracks shipped in archives")
>> * freespace2 - 784953 both URLs download fine with a fresh IP 784952
>> appears to be fixed in (at least) v44, but maintainer is asking for a
>> better long term solution (no response for 6 months), should the bug
>> still be closed? Is it expected that maintainers will stop bugs
>> closing if they want, or would it be better to clone it?
784953 is about donwload greylisting beyond our control
784952 is about lack of cooperation with freespace2 package:
That's why we have that for now:
mod.ini:
download: http://anonscm.debian.org/cgit/users/onlyjob/freespace2.git/plain/debian/packages/freespace2-data-gog/debian/mod.ini
distinctive_name: false
FS2.bmp:
download: http://anonscm.debian.org/cgit/users/onlyjob/freespace2.git/plain/debian/packages/freespace2-data-gog/debian/FS2.bmp
Now someone should tell Freespace2 maintainer that if he goes GDP way he can get rid of these two bugs ;-)
https://bugs.debian.org/cgi-bin/pkgreport.cgi?repeatmerged=no&src=freespace2
#777621 [m|M| ] [freespace2] freespace2-data-gog fails to build on case sensitive filesystem
#743067 [w| | ] [freespace2] freespace2: support for newer (? older? different?) gog.com installer
>> Additionally running `game-data-packager freespace2` fails immediately after on
>> mod.ini "Response was not JSON", should I raise a fresh bug for this?
Didn't know about that. Yes please, with a traceback
Greets,
Alexandre
Attachment:
signature.asc
Description: This is a digitally signed message part.