I've been maintaining a number of Perl software packages recently.
There's
SReview,
my video review and transcoding system of which I split off
Media::Convert a while
back; and as of about a year ago, I've also added
PtLink, an RSS aggregator
(with future plans for more than just that).
All these come with extensive test suites which can help me ensure that
things continue to work properly when I play with things; and all of
these are hosted on salsa.debian.org, Debian's gitlab instance. Since
we're there anyway, I configured GitLab CI/CD to run a full test suite
of all the software, so that I can't forget, and also so that I know
sooner rather than later when things start breaking.
GitLab has extensive support for various test-related reports, and while
it took a while to be able to enable all of them, I'm happy to report
that today, my perl test suites generate all three possible reports.
They are:
- The
coverage regex, which captures the total reported coverage for
all modules of the software; it will show the test coverage on the
right-hand side of the job page (as in this
example), and
it will show what the delta in that number is in merge request
summaries (as in this
example
- The JUnit report, which tells GitLab in detail which tests were run,
what their result was, and how long the test took (as in this
example)
- The cobertura report, which tells GitLab which lines in the software
were ran in the test suite; it will show up coverage of affected lines
in merge requests, but nothing more. Unfortunately, I can't show an
example here, as the information seems to be no longer available once
the merge request has been merged.
Additionally, I also store the native perl Devel::Cover report as job
artifacts, as they show some information that GitLab does not.
It's important to recognize that not all data is useful. For instance,
the JUnit report allows for a test name and for details of the test.
However, the module that generates the JUnit report from
TAP test suites does not make a
distinction here; both the test name and the test details are reported
as the same. Additionally, the time a test took is measured as the time
between the end of the previous test and the end of the current one;
there is no "start" marker in the TAP protocol.
That being said, it's still useful to see all the available information
in GitLab. And it's not even all that hard to do:
test:
stage: test
image: perl:latest
coverage: '/^Total.* (\d+.\d+)$/'
before_script:
- cpanm ExtUtils::Depends Devel::Cover TAP::Harness::JUnit Devel::Cover::Report::Cobertura
- cpanm --notest --installdeps .
- perl Makefile.PL
script:
- cover -delete
- HARNESS_PERL_SWITCHES='-MDevel::Cover' prove -v -l -s --harness TAP::Harness::JUnit
- cover
- cover -report cobertura
artifacts:
paths:
- cover_db
reports:
junit: junit_output.xml
coverage_report:
path: cover_db/cobertura.xml
coverage_format: cobertura
Let's expand on that a bit.
The first three lines should be clear for anyone who's used GitLab CI/CD
in the past. We create a job called
test; we start it in the
test
stage, and we run it in the
perl:latest docker image. Nothing
spectacular here.
The
coverage line contains a regular expression. This is applied by
GitLab to the output of the job; if it matches, then the first bracket
match is extracted, and whatever that contains is assumed to contain the
code coverage percentage for the code; it will be reported as such in
the GitLab UI for the job that was ran, and graphs may be drawn to show
how the coverage changes over time. Additionally, merge requests will
show the delta in the code coverage, which may help deciding whether to
accept a merge request. This regular expression will match on a line of
that the
cover program will generate on standard output.
The
before_script section installs various perl modules we'll need
later on. First, we intall
ExtUtils::Depends. My code
uses
ExtUtils::MakeMaker,
which ExtUtils::Depends depends on (no pun intended); obviously, if your
perl code doesn't use that, then you don't need to install it. The next
three modules --
Devel::Cover,
TAP::Harness::JUnit and
Devel::Cover::Report::Cobertura
are necessary for the reports, and you should include them if you want
to copy what I'm doing.
Next, we install declared dependencies, which is probably a good idea
for you as well, and then we run
perl Makefile.PL, which will generate
the Makefile. If you don't use ExtUtils::MakeMaker, update that part to
do what your build system uses. That should be fairly straightforward.
You'll notice that we don't actually
use the Makefile. This is because
we only want to run the test suite, which in our case (since these are
PurePerl modules) doesn't require us to build the software first. One
might consider that this makes the call of
perl Makefile.PL useless,
but I think it's a useful test regardless; if that fails, then obviously
we did something wrong and shouldn't even try to go further.
The actual tests are run inside a
script snippet, as is usual for
GitLab. However we do a bit more than you would normally expect; this is
required for the reports that we want to generate. Let's unpack what we
do there:
cover -delete
This deletes any coverage database that might exist (e.g., due to
caching or some such). We don't actually expect any coverage database,
but it doesn't hurt.
HARNESS_PERL_SWITCHES='-MDevel::Cover'
This tells the TAP harness that we want it to load the Devel::Cover
addon, which can generate code coverage statistics. It stores that in
the
cover_db directory, and allows you to generate all kinds of
reports on the code coverage later (but we don't do that here, yet).
prove -v -l -s
Runs the actual test suite, with
verbose output,
shuffling (aka,
randomizing) the test suite, and adding the
lib directory to perl's
include path. This works for us, again, because we don't actually need
to compile anything; if you do, then
-b (for
blib) may be required.
ExtUtils::MakeMaker creates a
test target in its Makefile, and usually
this is how you invoke the test suite. However, it's not the only way to
do so, and indeed if you want to generate a JUnit XML report then you
can't do that. Instead, in that case, you need to use the
prove, so
that you can tell it to load the TAP::Harness::JUnit module by way of
the
--harness option, which will then generate the JUnit XML report.
By default, the JUnit XML report is generated in a file
junit_output.xml. It's possible to customize the filename for this
report, but GitLab doesn't care and neither do I, so I don't. Uploading
the JUnit XML format tells GitLab which tests were run and
Finally, we invoke the
cover script twice to generate two coverage
reports; once we generate the default report (which generates HTML files
with detailed information on all the code that was triggered in your
test suite), and once with the
-report cobertura parameter, which
generates the cobertura XML format.
Once we've generated all our reports, we then need to upload them to
GitLab in the right way. The native perl report, which is in the
cover_db directory, is uploaded as a regular job artifact, which we
can then look at through a web browser, and the two XML reports are
uploaded in the correct way for their respective formats.
All in all, I find that doing this makes it easier to understand how my
code is tested, and why things go wrong when they do.
DebConf23, the 24th annual Debian Developer Conference,
is taking place in Kochi, India from September 10th to 17th, 2023.
Debian contributors from all over the world have come together at Infopark, Kochi
to participate and work in a conference exclusively run by volunteers.
Today the main conference starts with over 373 expected attendants and 92
scheduled activities, including 45-minute and 20-minute talks, Bird of a Feather
("BoF") team meetings, workshops, a job fair, as well as a variety of other
events.
The full schedule is updated each
day, including activities planned ad-hoc by attendees over the course of the
conference.
If you would like to engage remotely, you can follow the video streams
available from the DebConf23 website for the events happening in the three talk
rooms: Anamudi, Kuthiran and Ponmudi. Or you can join the conversations
happening inside the talk rooms via the OFTC IRC network
in the #debconf-anamudi, #debconf-kuthiran, and the #debconf-ponmudi
channels. Please also join us in the #debconf channel for common discussions
related to DebConf.
You can also follow the live coverage of news about DebConf23 provided by our
micronews service or the @debian profile on your
favorite social network.
DebConf is committed to a safe and welcoming environment for all participants.
Please see our Code of Conduct page on the DebConf23 website for more
information on this.
Debian thanks the commitment of numerous sponsors to support DebConf23,
particularly our Platinum Sponsors: Infomaniak, Proxmox and Siemens.
~
Daniel Knowles Carmageddon: How Cars Make Life Worse and What to
Do About It is an entertaining, lucid, and well-written manifesto
(to borrow a term from the author) aiming to get us all thinking a bit
more about what cars do to society, and how to move on to a better
outcome for all.
The book alternates between historical context and background, lived
experience (as the author is a foreign correspondent who had the
opportunity to travel), and researched content. It is refreshingly free
of formalities (no endless footnotes or endnotes with references, though
I would have liked occassional references but hey we all went to school
long enough to do a bit of research given a pointer or two). I learned
or relearned a few things as I was for example somewhat unaware of the
air pollution (micro-particle) impact stemming from tires and brake
abrasions for which electronic vehicles do zilch, and for which the
auto-obesity of ever larger and heavier cars is making things
much worse. And some terms (even when re-used by Knowles) are clever
such bionic duckweed. But now you need to read the book to
catch up on it.
Overall, the book argues its case rather well. The author brings
sufficient evidence to make the formal guilty charge quite convincing.
It is also recent having come out just months ago, making current
figures even more relevant.
I forget the exact circumstance but I think I came across the author
in the context of our joint obsession with both Chicago and cycling (as
there may have been a link from a related social media post) and/or the
fact that I followed some of his colleagues at The Economist on
social media. Either way, the number of Chicago and MidWest references
made for some additional fun when reading the book over a the last few
days. And for me another highlight was the ode to Tokyo which I
wholeheartedly agree with: on my second trip to Japan I spent a spare
day cycling across the city as the AirBnB host kindly gave me access to
his bicycles. Great weather, polite drivers, moderate traffic, and just
wicked good infrastructure made me wonder why I did not see more
cyclists.
I have little to criticize beyond the lack of any references. The
repeated insistence on reminding us that Knowles comes from Birmingham
gets a little old by the fifth or sixth repetition. It is all a wee bit
anglo- or UK-centric. It obviously has a bit on France, Paris,
and all the recent success of Anne Hidalgo (who, when I was in graduate
school in France, was still a TV person rather than the very successful
mayor she is now) but then does not mention the immense (and well known)
success of the French train system which lead to a recent dictum to no
longer allow intra-Frace air travel if train rides of under 2 1/2 hours
are available which is rather remarkable. (Though in fairness that may
have been enacted once the book was finished.)
Lastly, the book appears to have 
I ve just finalised the OpenPGP key list for the 
PS: Debian uploads for bubble-gum are moving along. Please if you have any packaging you need done in Debian proper, let me know and I will get on it, time allowing of course.
CRAN processed the package fully automatically as it has no issues, and
nothing popped up in reverse-dependency checking.
The set of changes for the last two RcppArmadillo releases
follows.
As is traditional for the UK August Bank Holiday weekend I made my way to Cambridge for the Debian UK BBQ. As was pointed out we ve been doing this for more than 20 years now, and it s always good to catch up with old friends and meet new folk.
Thanks to 
There is a bit of context that needs to be shared before I get to this and would be a long one. For reasons known and unknown, I have a lot of sudden electricity outages. Not just me, all those who are on my line. A discussion with a lineman revealed that around 200+ families and businesses are on the same line and when for whatever reason the electricity goes for all. Even some of the traffic lights don t work. This affects software more than hardware or in some cases, both. And more specifically HDD s are vulnerable. I had bought an APC unit several years for precisely this, but over period of time it just couldn t function and trips also when the electricity goes out. It s been 6-7 years so can t even ask customer service to fix the issue and from whatever discussions I have had with APC personnel, the only meaningful difference is to buy a new unit but even then not sure this is an issue that can be resolved, even with that.
That comes to the issue that happens once in a while where the system fsck is unable to repair /home and you need to use an external pen drive for the same. This is my how my hdd stacks up 
The main argument as have shared before is that Indian Govt. thinks we need our home grown CPU and while I have no issues with that, as shared before except for RISC-V there is no other space where India could look into doing that. Especially after the Chip Act, Biden has made that any new fabs or any new thing in chip fabrication will only be shared with 
. Backups certainly make a lot of sense, especially 
