Re: Ouput of reprotest under salsa-ci

2020-04-10 Thread Inaki Malerba
Hi Elías,

El 10/4/20 a las 01:05, Elías Alejandro escribió:
> Hello all,
> I have a dummy question about the output of reprotest under the salsa-ci 
> process.
> -How can I interpret or understand the following output log?:
> 
>  Binary files 
>  
> /builds/elias-guest/gpick/debian/output/reprotest/control/source-root/gpick-dbgsym_0.2.6~rc1-3+salsaci_amd64.deb
>  
>  and 
>  
> /builds/elias-guest/gpick/debian/output/reprotest/experiment-1/source-root/gpick-dbgsym_0.2.6~rc1-3+salsaci_amd64.deb
>  differ
>  
> The complete log is[1] I've downloaded the artifacts to look into the files 
> and
> I've found that the binary executables are differ with pkgdiff but with hex 
> numbers.
> Do you know where are the 'diff issues' for fix them? or 
> How can I get a complete information about them?

There's a tool to compare this kind of differences called Diffoscope[0].

You can download both packages from the Salsa CI pipeline (from the
build job and from the reprotest job) and use Diffoscope to compare them.

Also, you can enable 2 features on the Salsa CI pipeline to help you
debugging this: you can run diffoscope directly on the reprotest job [1]
which will tell you more details about the problem directly on the log,
and you can split reprotest variations [2] into different jobs to
identify which one is causing the problems on your package.

Abrazos!


0_ https://diffoscope.org/
1_
https://salsa.debian.org/salsa-ci-team/pipeline#running-reprotest-with-diffoscope
2_
https://salsa.debian.org/salsa-ci-team/pipeline#breaking-up-the-reprotest-job-into-the-different-variations

-- 
- ina



signature.asc
Description: OpenPGP digital signature


Re: Advice on packaging new upstream releases.

2020-02-16 Thread Inaki Malerba
Hi Sergio !

El 15/2/20 a las 19:24, Sergio Durigan Junior escribió:
> On Saturday, February 15 2020, Inaki Malerba wrote:
> 
>> Hi everyone!
> 
> Hey Inaki,
> 
>> I'm looking for some advice on how to fix some problems on 2 different
>> packages I've been trying to update with no luck so far.
>>
>> # python-icecream. [0][1]
>>
>> The new release includes a dependency to a very small repository [2]
>> that's not packaged.
>>
>> My first thought was to open an ITP and try to package it, but it turns
>> out to be a single python script and I'm not sure if it's reasonable to
>> create a whole package for that.
>>
>> Should I package the new dependency? The README[3] even suggests that
>> it's ok to copy that single file. Would it be OK if I patch it into my
>> package?
> 
> It's not uncommon to see small Python packages out there, often with
> only a single file, like this one.  IMO, you should go ahead and package
> it properly.  Other packages might depend on it, and it seems like an
> easy package to make anyway.

Thanks ! I already sent the ITP and i'll try to do the packaging today.
It's really small, I hope it goes fast through NEW.

> 
>> # doit [4][5]
>>
>> The latest release of this package contains a huge change on the
>> documentation, which breaks the linting. It contains a lot of external
>> javascripts and stuff.
>>
>> As python-icecream, doit made a change to depend on a custom sphinx
>> theme that's not packaged but I managed to fix that patching it to use
>> the default theme[6].
>>
>> Having changed the theme and fixed one of lintian suggestions (the
>> node-html5shiv one), there are still a lot of problems with the docs
>> package[7]. I even thought of removing the python-doit-doc package.
> 
> This one is more complicated...
> 
> Apparently upstream decided to write an index.html documentation page
> full of minified, non-Free JS:
> 
>   
> https://github.com/pydoit/doit/commit/e7717d705d60731f750f1e27e0f633c3d0502678
> 
> If you look at index.html's header, you'll see references to things
> under the _static/vendor directory, or links to fonts.googleapis.com.
> Both are problematic:
> 
>   https://github.com/pydoit/doit/blob/master/doc/index.html#L10-L26
> 
> We have almost everything packaged in Debian that is needed to replace
> these.  You will have to remove the files from the tarball (using
> d/copyright's Files-Excluded, plus using +dfsg in the package's
> version).
> 
> These are the replacements that already exist in Debian:
> 
>   libjs-bootstrap (for bootstrap.min.js)
>   fonts-font-awesome (for font-awesome.min.css)
>   fonts-roboto (for the googleapis.com Roboto font)
> 
> We're missing packages for "bootstrap-select.min.css" and
> "owl.carousel".  The good thing about "owl.carousel" is that python-doit
> ships the non-minified JS version, which means that you can minify it
> during build time.  The problematic part is the
> "bootstrap-select.min.css" file, which is only shipped in its minified
> version.
> 
> The ideal scenario would be to package bootstrap-select and then depend
> on it, but I don't think it's fair to make you go through this (the
> package seems a bit complicated, and packaging JS is not easy
> sometimes).  Another "good enough" approach (IMO) would be to copy a
> version of "bootstrap-select.js" (non-minified) into python-doit's code
> (using a patch under d/patch, of course), and then minify it during the
> build.  This is not very elegant, but solves the problem (it's similar
> to what you proposed above, for python-icecream).
> 
> All in all, it will demand a bit of work, unfortunately.

Excellent. I'll try to go with the patching of bootstrap-select.js option.

Why should I include the non-minified version? For reading purposes?
Never thought of it but makes sense.

Thanks a lot :)

> 
> Thanks,
> 


-- 
- ina



signature.asc
Description: OpenPGP digital signature


Advice on packaging new upstream releases.

2020-02-15 Thread Inaki Malerba
Hi everyone!

I'm looking for some advice on how to fix some problems on 2 different
packages I've been trying to update with no luck so far.

# python-icecream. [0][1]

The new release includes a dependency to a very small repository [2]
that's not packaged.

My first thought was to open an ITP and try to package it, but it turns
out to be a single python script and I'm not sure if it's reasonable to
create a whole package for that.

Should I package the new dependency? The README[3] even suggests that
it's ok to copy that single file. Would it be OK if I patch it into my
package?


# doit [4][5]

The latest release of this package contains a huge change on the
documentation, which breaks the linting. It contains a lot of external
javascripts and stuff.

As python-icecream, doit made a change to depend on a custom sphinx
theme that's not packaged but I managed to fix that patching it to use
the default theme[6].

Having changed the theme and fixed one of lintian suggestions (the
node-html5shiv one), there are still a lot of problems with the docs
package[7]. I even thought of removing the python-doit-doc package.


What should I do here?

Thanks in advance :)



0_ https://github.com/gruns/icecream
1_ https://salsa.debian.org/debian/python-icecream
2_ https://github.com/alexmojaki/executing
3_ https://github.com/alexmojaki/executing#installation
4_ https://github.com/pydoit/doit/
5_ https://salsa.debian.org/debian/doit/
6_
https://salsa.debian.org/debian/doit/blob/master/debian/patches/restore_docs_theme.diff
7_ https://salsa.debian.org/debian/doit/-/jobs/481358


-- 
- ina



signature.asc
Description: OpenPGP digital signature