]> pere.pagekite.me Git - homepage.git/blobdiff - blog/archive/2024/04/04.rss
Generated.
[homepage.git] / blog / archive / 2024 / 04 / 04.rss
index ccc44125167919d8af3244721e27d3497295e682..6b4e0520e06fd3519e1201f4502ab735573f959c 100644 (file)
@@ -6,6 +6,181 @@
                 <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>