Hello! I have taken into consideration the information and corrections and here is the updated repo https://salsa.debian.org/Ayoyimika/node-trust-json-document
Thanks and Cheers On Sat, Feb 12, 2022 at 2:26 PM Jonas Smedegaard <jo...@jones.dk> wrote: > > [ adding back mailinglist as recipient ] > > Quoting Ayoyimika Ajibade (2022-02-12 07:00:54) > > > update webpack command > > As part of the migration to webpack5, some options are no more valid > > example is the -d or -p option which was previously referred to set > > the development or production environment respectively, hence the > > change was the functional effect (e.g needed for webpack5), which will > > try to make my commit messages more descriptive. Thanks for putting > > that in. > > Ah, it is news to me that webpack5 does not support the short-form > options. > > Related note: I run a few Debian systems - laptops and servers - and on > all of them I install the package apt-listchanges, which shows package > changes each time I run "apt update && apt update" - which I do at least > once per day (yeah, I should maybe talk to a psyciatrist about that). > By default, apt-listchanges show only entries from NEWS files, but I > reconfigure it with "dpkg-reconfigre apt-listchanges" to also show > Changelog entries. In short, I read (or skim, very quickly) all changes > for all packages on my systems. I learn a lot from informative changelog > messages. > > I find it an amusing little challenge for myself to express changelog > messages to be both short and informative. I am not very good at it - > for inspiration I can recommend looking at changelog messages (and > mailinglist posts) by Simon McVittie - e.g. gtk4: > https://tracker.debian.org/media/packages/g/gtk4/changelog-4.6.0ds1-4 > > I commonly follow one of these patterns for changelog entries: > > * tedious change done > * change done, highlighting additions > * change done, highlighting additions (highlighting omissions) > > Here, I would maybe write (exactly as you - I am no saint, or) like > this: > > * update webpack command, to be forward-compatible with webpack5 > > It is common to fit most possible (i.e. as close to 72 chars) before > wrapping a line. I instead break at natural "pauses" in the text, > called "semantic newlines": https://sembr.org/ > > > > > Change #2: You update DEP-3 header of a patch > > will make necessary changes to the patch > > I suggest to *drop* that patch: It is not necessary, just makes the > patch one line bigger. > > > > > fix install in binary packages > > don't know if that is the right word 'fix' but there were lots of > > errors thrown from dh_missing as files were not properly installed > > even for autopkgtest to use. Please if i may ask why the need for > > another binary file i.e > > libjs-trust-json-document_0.1.4~dfsg-11_all.deb > > I didn't check but am pretty sure that if you did not apply the next > commit to use pkg-js-tools, then dh_missing would be silent. > > So what you "fixed" was your own changes, not something in the previous > package release, and therefore your "fix" does not belong in the > _changelog_ (it is not an activity log). > > Common procedure when building a package is this: > > a) prepare sources > b) configure upstream build system > c) do an upstream "build" > d) do an upstream "install" to debian/tmp > e) copy files from debian/tmp to debian/$PKG > f) finalize packaging > > Node.js packages often provide no upstream "install" task that fits the > Debian needs. > > This package skipped d) and in e) copies directly from source paths. > dh_missing should not complain about that. > > Your later commit introduces pkg-js-tools to handle d) and e), and > dh_missing then (correctly) complains that something weird is going on: > files are copied twice. > > > > > migrate to pkg-js-tools and autopkgtest to handle test suites > > sure i will revert the change, as i wanted to test with autopkgtest. > > from my limited knowledge, I switched to pkg-js packaging style. Is > > there any way I can do that? > > Make good sense to improve test coverage. > > Yes, it is possible to use autopkgtest without pkg-js. Not as easy, but > possible more reliable. > > autopkgtest already runs a few superficial tests now, before your > packaging changes: It is setup in the directory debian/tests/ > > I guess what you want is to _improve_ autopkgtest, to not only do > superficial tests but also check upstream testsuite (which is currently > checked only during build). > > Upstream testsuite is not designed to check Debian-installed code. Maybe > pkg-js magically ensures this, but possibly it accidentally checks > source code instead, which is less useful. > > One example of a package that checks upstream Node.js testsuite and > ensures that system-installed module gets loaded (not local code) is > node-lunr: run "apt source node-lunr" and see debian/tests/control > > Beware that the upstream testsuite for this package seemingly does *not* > test webpack-generated code, only uncompressed code - so even though > including upstream testsuite with autopkgtest _is_ a good improvement to > the packaging, it will _not_ help tracking if webpack migration works or > not. > > The purpose of webpack is generally to make JavaScript usable in a > browser, so testing that in principle requires loading the code in a > browser as well. test-friendly wrappers for browser JavaScript engines > exist but are rare in Debian, mainly because compiling a modern web > browser is a HUUUGE task. > > For some simpler Node.js modules, their browser-optimized code can > instead be tested using a crude emulator of a browser environment. One > package that does this is node-domino. > > Another even simpler but more reliable test is to only check JavaScript > syntax without executing the code. A package to do that is eslint. > > Examples of packages doing domino and eslint tests of browser code are > libjs-bootbox, node-terser, and leaflet. > > > - Jonas > > -- > * Jonas Smedegaard - idealist & Internet-arkitekt > * Tlf.: +45 40843136 Website: http://dr.jones.dk/ > > [x] quote me freely [ ] ask before reusing [ ] keep private -- Pkg-javascript-devel mailing list Pkg-javascript-devel@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel
