New lintian warnings helping to detect FTBFS and license violation
Hi, Newest lintian will detect a few new problems in our package. It will first detect minified javascript/css embedded in html file (source only). It it possible to avoid this warning by creating a symlink to source or adding source under debian/missing-source/$nameoffile.fragment (better naming welcome). It will also detect html file that include script with a copyright statement. These scripts were likely copy-pasted and likely needs to be rebuilt from the original source. Moreover they may be also outdated and may need need to be updated from a security point of view. [1] They are a few false positive that will fixed ASAP. Last but not least, lintian will detect browserify/webpack source both in html included script and js file [2]. These file should be rebuilt from source (I am now packaging browserify to main. Technically they are also some problem with browserified file that need to be rebuilt each time a depends change). Bastien [1] https://lintian.debian.org/tags/embedded-script-includes-copyright-statement.html [2] https://lintian.debian.org/tags/source-contains-browserified-javascript.html signature.asc Description: This is a digitally signed message part.
Feedback request about the Alba Upstream to Debian packaging effort
Hello, the Alba[1] synchrotron radiation facilities, recently switch to Debian for their OS. They are part of the Tango[2] control system community which contain most of the European Synchrotron Radiation Facilities and others[3]. At least three instituts have already choosen Debian (partially Soleil, ESRF, petraIII, and Alba). The next meeting of this community will be held in Prague[4] next week. During this meeting, Alba will present their plan about packaging "Collaborative and automated Packaging"[5]. The idea is to propose a pipeline via a .gitlab-ci.yml[6] file which should be added to the upstream repository and/or in a repository dedicated to packaging, in order to generate debian packages ready to install software on their facility or ready to upload into Debian. Since I am not at all a specialist of gitlab-ci, I would like your advice on the pipeline, and also on the numbering scheme propose by Alba. In fact all feedback which should smooth the upstream to debian flow. Thanks for considering. Frederic Ps: Please keep the CC, they are not yet subscribers of debian-devel [1] https://www.cells.es/en [2] http://www.tango-controls.org/ [3] http://www.tango-controls.org/partners/institutions/ [4] https://indico.eli-beams.eu/event/310/other-view?view=standard#20180605.detailed [5] https://people.debian.org/~picca/CollabPkg-v3.pdf [6] https://people.debian.org/~picca/gitlab-ci.yml
Re: [good new]Type 1 font hinting is now free software
On Jun 01, Bastien ROUCARIÈS wrote: > The license choosen by adobe is unfortunalty apache 2 and thus not compatible > with GPL2 only. In which cases this would be relevant? -- ciao, Marco signature.asc Description: PGP signature
Re: packages which have not been rebuild since December 2016
On 01-06-18 16:32, Chris Lamb wrote: > … wouldn't we just binNMU these? There are many packages in your list that are arch:all only, and those can't be binNMU'ed. Still I'm not sure we can do some several thousand binNMUs. But that number could get reduced due to maintainer uploads and binNMUs due to unrelated transitions. Cheers, Emilio
Re: [good new]Type 1 font hinting is now free software
On Fri, Jun 1, 2018 at 10:35 PM, Marco d'Itri wrote: > On Jun 01, Bastien ROUCARIÈS wrote: > >> The license choosen by adobe is unfortunalty apache 2 and thus not compatible >> with GPL2 only. > In which cases this would be relevant? If font is GPL2 only, is type 1 and use font hinting it is a license violation. Lintian detect the type 1 font hinting here: https://lintian.debian.org/tags/license-problem-font-adobe-copyrighted-fragment.html https://lintian.debian.org/tags/license-problem-font-adobe-copyrighted-fragment-no-credit.html We could check debian/copyright if dep5 but patch is welcome (and it need to be clever if font is build from source we only check build font). I suppose the lintian check need to be redone type 1 font hinting is quite current Bastien Bastien > > -- > ciao, > Marco
Re: packages which have not been rebuild since December 2016
On Sat, Jun 02, 2018 at 10:36:58AM +0200, Emilio Pozuelo Monfort wrote: > On 01-06-18 16:32, Chris Lamb wrote: > > … wouldn't we just binNMU these? > There are many packages in your list that are arch:all only, and those can't > be > binNMU'ed. Still I'm not sure we can do some several thousand binNMUs. But > that > number could get reduced due to maintainer uploads and binNMUs due to > unrelated > transitions. also, binNMUs break multi-arch, see #894441, so I'm not a fan (of the current implementation of) binNMUs. -- cheers, Holger signature.asc Description: PGP signature
Re: path to gitlab upstream
Geert Stappers writes ("path to gitlab upstream"):
> There is https://gitlab.com/gitlab-org/gitlab-ce/
> It has currently 10,712 issues and 595 merge requests.
>
> About the issues: Open: 10,712 Closed: 25,941 All: 36,653
> MR: Open: 595 Merged: 15,906 Closed 2,696 All: 19,198
>
> That tells me that a Merge Request has a better success ratio.
> Also that it is wise to keep notes of the MR number :-/
I doubt it would be sensible for me to (probably incompetently)
reimplement the feature that the proprietary Gitlab EE has in this
area, and then send the result as an MR against Gitlab CE. It seems
more likely that enquiring politely in advance would be well-received.
Does anyone think I am wrong about that ?
Ian.
--
Ian JacksonThese opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
Re: Feedback request about the Alba Upstream to Debian packaging effort
PICCA Frederic-Emmanuel writes ("Feedback request about the Alba Upstream to
Debian packaging effort"):
> Since I am not at all a specialist of gitlab-ci, I would like your
> advice on the pipeline, and also on the numbering scheme propose by
> Alba. In fact all feedback which should smooth the upstream to debian
> flow.
...
> [5] https://people.debian.org/~picca/CollabPkg-v3.pdf
I didn't have a massive amount of time to review this in detail, but
it sounds cool. I looked at the slides in the pdf [5] above.
(Shame there isn't a technical report...)
I reviewed the version number proposal and it seems sound to me.
I have some observations:
You probably want to keep the delta between the upstream and the
debianised branch as small as possible.
On build systems and debian/ruless: if (i) you can get as much of your
upstream build system looking as standard as possible (ii) you can get
as much of the rest supported by dh as possible, then your
debian/rules files could possibly be very small indeed.
debian/changelog is a bit of a pain and you will have to write code to
generate it. [gbp-]dch can be helpful.
Ideally you would treat debian/control as an output file: generate it
entirely from upstream stuff, using some tool, and commit the result
as a committed-artefact to the debianised branch.
Your debianisation tool becomes part of the source code for your
packages. You need to publish it in your repository, track the
version used, etc. So it probably needs to be debianised. I think
you need to mention it in Built-Using or something similar.
Finally, and VERY CONTROVERSIALLY: consider whether you want to bother
with source packages. You could just use git branches instead.
Source packages are a pain.
Good luck and have fun!
Ian.
--
Ian JacksonThese opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
Re: New lintian warnings helping to detect FTBFS and license violation
Hello Bastien and others, On Sat, Jun 02 2018, Bastien ROUCARIÈS wrote: > It will first detect minified javascript/css embedded in html file > (source only). It it possible to avoid this warning by creating a > symlink > to source or adding source under > debian/missing-source/$nameoffile.fragment (better naming welcome). There is a already a convention for naming the files documented in the Policy Manual. Please use that. In particular, it's d/missing-sources not d/missing-source. Section 4.16: https://www.debian.org/doc/debian-policy/#missing-sources-debian-missing-sources -- Sean Whitton
Re: path to gitlab upstream
On 02/06/2018 15:25, Ian Jackson wrote: >> That tells me that a Merge Request has a better success ratio. >> Also that it is wise to keep notes of the MR number :-/ > > I doubt it would be sensible for me to (probably incompetently) > reimplement the feature that the proprietary Gitlab EE has in this > area, and then send the result as an MR against Gitlab CE. It seems > more likely that enquiring politely in advance would be well-received. > Does anyone think I am wrong about that ? Inquiring first seems like a very sensible thing to do. Maybe they could even suggest a way to implement the functionality by some kind of hook or something without directly modifying upstream code (or maybe they will be glad to implement the ability to do so). I ran in to issues with wanting to change the favicon too for salsa, because I have way too many different gitlab tabs and they all look the same and there's no sensible way to change it for salsa right now (I tried out a bunch of regexes to do it in the reverse proxy but after an hour or so I decided to rather get some pizza). -Jonathan
Re: packages which have not been rebuild since December 2016
Hi Holger, > at the MiniDebConf 2018 in Hamburg we listed a few issues in Debian with > regards to making Debian Buster reproducible in practice. (*) > > One issue we forgot to mention there is that Given that we forgot to mention this issue at least once, I would like to create a bug in the BTS for it. This would have the advantages of being a good place to store the latest status as well as being a convenient way to link others to it. I'd be happy to summarise the replies to the thread thus far, please just let me know which package I should assign it to (general? buildd.debian.org? I'm easy...) Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org / chris-lamb.co.uk `-
