Generated.

[homepage.git] / blog / archive / 2024 / 04 / 04.rss

<?xml version="1.0" encoding="ISO-8859-1"?>
<rss version='2.0' xmlns:lj='http://www.livejournal.org/rss/lj/1.0/'>
        <channel>
                <title>Petter Reinholdtsen - Entries from April 2024</title>
                <description>Entries from April 2024</description>
                <link>https://people.skolelinux.org/pere/blog/</link>

        
        <item>
                <title>45 orphaned Debian packages moved to git, 391 to go</title>
                <link>https://people.skolelinux.org/pere/blog/45_orphaned_Debian_packages_moved_to_git__391_to_go.html</link>        
                <guid isPermaLink="true">https://people.skolelinux.org/pere/blog/45_orphaned_Debian_packages_moved_to_git__391_to_go.html</guid>
                <pubDate>Thu, 25 Apr 2024 22:00:00 +0200</pubDate>
                <description>&lt;p&gt;Nine days ago, I started migrating orphaned Debian packages with no
version control system listed in debian/control of the source to git.
At the time there were 438 such packages.  Now there are 391,
according to the UDD.  In reality it is slightly less, as there is a
delay between uploads and UDD updates.  In the nine days since, I have
thus been able to work my way through ten percent of the packages.  I
am starting to run out of steam, and hope someone else will also help
brushing some dust of these packages.  Here is a recipe how to do it.

I start by picking a random package by querying the UDD for a list of
10 random packages from the set of remaining packages:

&lt;blockquote&gt;&lt;pre&gt;
PGPASSWORD=&quot;udd-mirror&quot; psql --port=5432 --host=udd-mirror.debian.net \
  --username=udd-mirror udd -c &quot;select source from sources \
   where release = &#39;sid&#39; and (vcs_url ilike &#39;%anonscm.debian.org%&#39; \
   OR vcs_browser ilike &#39;%anonscm.debian.org%&#39; or vcs_url IS NULL \
   OR vcs_browser IS NULL) AND maintainer ilike &#39;%packages@qa.debian.org%&#39; \
   order by random() limit 10;&quot;
&lt;/pre&gt;&lt;/blockquote&gt;

&lt;p&gt;Next, I visit http://salsa.debian.org/debian and search for the
package name, to ensure no git repository already exist.  If it does,
I clone it and try to get it to an uploadable state, and add the Vcs-*
entries in d/control to make the repository more widely known.  These
packages are a minority, so I will not cover that use case here.&lt;/p&gt;

&lt;p&gt;For packages without an existing git repository, I run the
following script &lt;tt&gt;debian-snap-to-salsa&lt;/tt&gt; to prepare a git
repository with the existing packaging.&lt;/p&gt;

&lt;blockquote&gt;&lt;pre&gt;
#!/bin/sh
#
# See also https://bugs.debian.org/804722#31

set -e

# Move to this Standards-Version.
SV_LATEST=4.7.0

PKG=&quot;$1&quot;

if [ -z &quot;$PKG&quot; ]; then
    echo &quot;usage: $0 &lt;pkgname&gt;&quot;
    exit 1
fi

if [ -e &quot;${PKG}-salsa&quot; ]; then
    echo &quot;error: ${PKG}-salsa already exist, aborting.&quot;
    exit 1
fi

if [ -z &quot;ALLOWFAILURE&quot; ] ; then
    ALLOWFAILURE=false
fi

# Fetch every snapshotted source package.  Manually loop until all
# transfers succeed, as &#39;gbp import-dscs --debsnap&#39; do not fail on
# download failures.
until debsnap --force -v $PKG || $ALLOWFAILURE ; do sleep 1; done
mkdir ${PKG}-salsa; cd ${PKG}-salsa
git init

# Specify branches to override any debian/gbp.conf file present in the
# source package.
gbp import-dscs  --debian-branch=master --upstream-branch=upstream \
    --pristine-tar ../source-$PKG/*.dsc

# Add Vcs pointing to Salsa Debian project (must be manually created
# and pushed to).
if ! grep -q ^Vcs- debian/control ; then
    awk &quot;BEGIN { s=1 } /^\$/ { if (s==1) { print \&quot;Vcs-Browser: https://salsa.debian.org/debian/$PKG\&quot;; print \&quot;Vcs-Git: https://salsa.debian.org/debian/$PKG.git\&quot; }; s=0 } { print }&quot; &lt; debian/control &gt; debian/control.new &amp;&amp; mv debian/control.new debian/control
    git commit -m &quot;Updated vcs in d/control to Salsa.&quot; debian/control
fi

# Tell gbp to enforce the use of pristine-tar.
inifile +inifile debian/gbp.conf +create +section DEFAULT +key pristine-tar +value True
git add debian/gbp.conf
git commit -m &quot;Added d/gbp.conf to enforce the use of pristine-tar.&quot; debian/gbp.conf

# Update to latest Standards-Version.
SV=&quot;$(grep ^Standards-Version: debian/control|awk &#39;{print $2}&#39;)&quot;
if [ $SV_LATEST != $SV ]; then
    sed -i &quot;s/\(Standards-Version: \)\(.*\)/\1$SV_LATEST/&quot; debian/control
    git commit -m &quot;Updated Standards-Version from $SV to $SV_LATEST.&quot; debian/control
fi

if grep -q pkg-config debian/control; then
    sed -i s/pkg-config/pkgconf/ debian/control
    git commit -m &quot;Replaced obsolete pkg-config build dependency with pkgconf.&quot; debian/control
fi

if grep -q libncurses5-dev debian/control; then
    sed -i s/libncurses5-dev/libncurses-dev/ debian/control
    git commit -m &quot;Replaced obsolete libncurses5-dev build dependency with libncurses-dev.&quot; debian/control
fi
&lt;/pre&gt;&lt;/blockquote&gt;

Some times the debsnap script fail to download some of the versions.
In those cases I investigate, and if I decide the failing versions
will not be missed, I call it using ALLOWFAILURE=true to ignore the
problem and create the git repository anyway.&lt;/p&gt;

&lt;p&gt;With the git repository in place, I do a test build (gbp
buildpackage) to ensure the build is actually working.  If it does not
I pick a different package, or if the build failure is trivial to fix,
I fix it before continuing.  At this stage I revisit
http://salsa.debian.org/debian and create the project under this group
for the package.  I then follow the instructions to publish the local
git repository.  Here is from a recent example:&lt;/p&gt;

&lt;blockquote&gt;&lt;pre&gt;
git remote add origin git@salsa.debian.org:debian/perl-byacc.git
git push --set-upstream origin master upstream pristine-tar
git push --tags
&lt;/pre&gt;&lt;/blockquote&gt;

&lt;p&gt;With a working build, I have a look at the build rules if I want to
remove some more dust.  I normally try to move to debhelper compat
level 13, which involves removing debian/compat and modifying
debian/control to build depend on debhelper-compat (=13).  I also test
with &#39;Rules-Requires-Root: no&#39; in debian/control and verify in
debian/rules that hardening is enabled, and include all of these if
the package still build.  If it fail to build with level 13, I try
with 12, 11, 10 and so on until I find a level where it build, as I do
not want to spend a lot of time fixing build issues.&lt;/p&gt;

&lt;p&gt;Some times, when I feel inspired, I make sure debian/copyright is
converted to the machine readable format, often by starting with
&#39;debhelper -cc&#39; and then cleaning up the autogenerated content until
it matches realities.  If I feel like it, I might also clean up
non-dh-based debian/rules files to use the short style dh build
rules.&lt;/p&gt;

&lt;p&gt;Once I have removed all the dust I care to process for the package,
I run &#39;gbp dch&#39; to generate a debian/changelog entry based on the
commits done so far, run &#39;dch -r&#39; to switch from &#39;UNRELEASED&#39; to
&#39;unstable&#39; and get an editor to make sure the &#39;QA upload&#39; marker is in
place and that all long commit descriptions are wrapped into sensible
lengths, run &#39;debcommit --release -a&#39; to commit and tag the new
debian/changelog entry, run &#39;debuild -S&#39; to build a source only
package, and &#39;dput ../perl-byacc_2.0-10_source.changes&#39; to do the
upload.  During the entire process, and many times per step, I run
&#39;debuild&#39; to verify the changes done still work.  I also some times
verify the set of built files using &#39;find debian&#39; to see if I can spot
any problems (like no file in usr/bin any more or empty package).  I
also try to fix all lintian issues reported at the end of each
&#39;debuild&#39; run.&lt;/p&gt;

&lt;p&gt;If I find Debian specific patches, I try to ensure their metadata
is fairly up to date and some times I even try to reach out to
upstream, to make the upstream project aware of the patches.  Most of
my emails bounce, so the success rate is low.  For projects with no
Homepage entry in debian/control I try to track down one, and for
packages with no debian/watch file I try to create one.  But at least
for some of the packages I have been unable to find a functioning
upstream, and must skip both of these.&lt;/p&gt;

&lt;p&gt;If I could handle ten percent in nine days, twenty people could
complete the rest in less then five days.  I use approximately twenty
minutes per package, when I have twenty minutes spare time to spend.
Perhaps you got twenty minutes to spare too?&lt;/p&gt;

&lt;p&gt;As usual, if you use Bitcoin and want to show your support of my
activities, please send Bitcoin donations to my address
&lt;b&gt;&lt;a href=&quot;bitcoin:15oWEoG9dUPovwmUL9KWAnYRtNJEkP1u1b&quot;&gt;15oWEoG9dUPovwmUL9KWAnYRtNJEkP1u1b&lt;/a&gt;&lt;/b&gt;.&lt;/p&gt;
</description>
        </item>
        
        <item>
                <title>RAID status from LSI Megaraid controllers in Debian</title>
                <link>https://people.skolelinux.org/pere/blog/RAID_status_from_LSI_Megaraid_controllers_in_Debian.html</link>        
                <guid isPermaLink="true">https://people.skolelinux.org/pere/blog/RAID_status_from_LSI_Megaraid_controllers_in_Debian.html</guid>
                <pubDate>Wed, 17 Apr 2024 17:00:00 +0200</pubDate>
                <description>&lt;p&gt;I am happy to report that
&lt;a href=&quot;https://github.com/namiltd/megactl&quot;&gt;the megactl package&lt;/a&gt;,
useful to fetch RAID status when using the LSI Megaraid controller,
now is available in Debian.  It passed NEW a few days ago, and is now
&lt;a href=&quot;https://tracker.debian.org/pkg/megactl&quot;&gt;available in
unstable&lt;/a&gt;, and probably showing up in testing in a weeks time.  The
new version should provide Appstream hardware mapping and should
integrate nicely with isenkram.&lt;/p&gt;

&lt;p&gt;As usual, if you use Bitcoin and want to show your support of my
activities, please send Bitcoin donations to my address
&lt;b&gt;&lt;a href=&quot;bitcoin:15oWEoG9dUPovwmUL9KWAnYRtNJEkP1u1b&quot;&gt;15oWEoG9dUPovwmUL9KWAnYRtNJEkP1u1b&lt;/a&gt;&lt;/b&gt;.&lt;/p&gt;

</description>
        </item>
        
        <item>
                <title>Time to move orphaned Debian packages to git</title>
                <link>https://people.skolelinux.org/pere/blog/Time_to_move_orphaned_Debian_packages_to_git.html</link>        
                <guid isPermaLink="true">https://people.skolelinux.org/pere/blog/Time_to_move_orphaned_Debian_packages_to_git.html</guid>
                <pubDate>Sun, 14 Apr 2024 09:30:00 +0200</pubDate>
                <description>&lt;p&gt;There are several packages in Debian without a associated git
repository with the packaging history.  This is unfortunate and it
would be nice if more of these would do so.  Quote a lot of these are
without a maintainer, ie listed as maintained by the
&#39;&lt;a href=&quot;https://qa.debian.org/developer.php?email=packages%40qa.debian.org&quot;&gt;Debian
QA Group&lt;/a&gt;&#39; place holder.  In fact, 438 packages have this property
according to UDD (&lt;tt&gt;SELECT source FROM sources WHERE release = &#39;sid&#39;
AND (vcs_url ilike &#39;%anonscm.debian.org%&#39; OR vcs_browser ilike
&#39;%anonscm.debian.org%&#39; or vcs_url IS NULL OR vcs_browser IS NULL) AND
maintainer ilike &#39;%packages@qa.debian.org%&#39;;&lt;/tt&gt;).  Such packages can
be updated without much coordination by any Debian developer, as they
are considered orphaned.&lt;/p&gt;

&lt;p&gt;To try to improve the situation and reduce the number of packages
without associated git repository, I started a few days ago to search
out candiates and provide them with a git repository under the
&#39;debian&#39; collaborative Salsa project.  I started with the packages
pointing to obsolete Alioth git repositories, and am now working my
way across the ones completely without git references.  In addition to
updating the Vcs-* debian/control fields, I try to update
Standards-Version, debhelper compat level, simplify d/rules, switch to
Rules-Requires-Root: no and fix lintian issues reported.  I only
implement those that are trivial to fix, to avoid spending too much
time on each orphaned package.  So far my experience is that it take
aproximately 20 minutes to convert a package without any git
references, and a lot more for packages with existing git repositories
incompatible with git-buildpackages.&lt;/p&gt;

&lt;p&gt;So far I have converted 10 packages, and I will keep going until I
run out of steam.  As should be clear from the numbers, there is
enough packages remaining for more people to do the same without
stepping on each others toes.  I find it useful to start by searching
for a git repo already on salsa, as I find that some times a git repo
has already been created, but no new version is uploaded to Debian
yet.  In those cases I start with the existing git repository.  I
convert to the git-buildpackage+pristine-tar workflow, and ensure a
debian/gbp.conf file with &quot;pristine-tar=True&quot; is added early, to avoid
uploading a orig.tar.gz with the wrong checksum by mistake.  Did that
three times in the begin before I remembered my mistake.&lt;/p&gt;

&lt;p&gt;So, if you are a Debian Developer and got some spare time, perhaps
considering migrating some orphaned packages to git?&lt;/p&gt;

&lt;p&gt;As usual, if you use Bitcoin and want to show your support of my
activities, please send Bitcoin donations to my address
&lt;b&gt;&lt;a href=&quot;bitcoin:15oWEoG9dUPovwmUL9KWAnYRtNJEkP1u1b&quot;&gt;15oWEoG9dUPovwmUL9KWAnYRtNJEkP1u1b&lt;/a&gt;&lt;/b&gt;.&lt;/p&gt;
</description>
        </item>
        
        </channel>
</rss>