Contributing to Ubuntu packages on Launchpad but with different hosting (e.g. GitHub)

Hi, I would like to contribute to an Ubuntu package but I can’t understand how to do it.

I reported a bug on the platform and an upstream fix is available. I would like to hence cherry-pick such fix and propose the package for upload on focal. However, it is not clear to me how to do that.

First, the code is not hosted on Launchpad itself but on GitHub, so I’m not sure how should I use Bazar to clone and reupload the package.
Second, how do I then ask the maintainers if it’s possible to upload to Focal.
Third, I think I should also tag the bug with some launchpad-bug-tags but the documentation doesn’t provide all of them.

I think in general the whole process is quite convoluted and the documentation is sparse and often outdated. Do you have some suggestion on where to look at?

I’d be very happy to help! :blush:

1 Like

The fix was applied in Debian and synced to groovy as version 38-2, which is a good start.

There is no VCS in use on the Ubuntu side, so you will need to just provide a patch in the form of a debdiff.

What you want to do is called a stable release update (SRU), and the procedure for such updates are described here:

https://wiki.ubuntu.com/StableReleaseUpdates

Basically you would need to:

  • Edit the bug description to comply with the SRU template
  • Attach a debdiff to the bug report
  • Ask somebody to upload it for you.

As regards the debdiff, looking at the difference between version 38-1 and 38-2 gives you an idea of what it should look like.

I changed the bug report so it targets focal.

2 Likes

Thank you very much for your help!

I added the SRU template to the description, provided the debdiff and subscribed the Ubuntu Sponsors Team. Should I contact anyone personally or just wait for somebody to appear?

Ok… I thought you would simply apply commit ed00ae61 on top of version 31-1. Now I see that you chose to propose a backport of 38-2 instead. That may be fine too, provided that the changes are bug fix ones and don’t include additional features.

The restrictiveness when SRUing is of course due to preventing regressions. In this case you could argue that it’s already broken, and can’t be much worse… That’s how I argued myself recently when helping with bug #1875498, and that was accepted by the SRU team.

Please note that you will need to add an extra entry at the top of debian/changelog. Something along these lines:

gnome-shell-extension-dash-to-panel (38-2~ubuntu20.04.1) focal; urgency=medium

  * Backport from groovy as an SRU (LP: #1892245)

 -- <your-real-name> <<your-email>>  Mon, 31 Aug 2020 21:00:00 +0200

I would strongly advise you to contact someone personally. In an ideal world you wouldn’t need to, but we don’t live in an ideal world…

2 Likes

Thank you very much, I reuploaded the patch, with the updated changelog and signed with my PGP key. I sent a message to Andy Whitcroft for review, I hope he’s still and SRU member. It was a bit complicated to figure out who to contact and by which mean :thinking:

Yeah, the procedure is not so easy to grasp for a first-timer (which was the reason why you started this topic in the first place, right?).

Actually there are multiple steps. First the package needs to simply be uploaded to focal. That can anybody with upload rights do, i.e. anbody who is a MOTU or Core Development Team member. So you could have asked anyone in those teams.

Once uploaded, the package is placed in a queue awaiting that someone in the SRU team will review and approve it. That’s a true queue (unlike the sponsorship queue nowadays), i.e. the SRU team is committed to handle all packages in the queue.

Anyway, hopefully Andy will help with the initial upload. A reminder on IRC might help. :wink: If he wouldn’t in due time, please let me know and I can ask someone else.

1 Like

Thank you very much for your help and support! I’ll keep you updated :blush:

I did not receive any answer so far, maybe I reached a no longer used address. I’ll try to contact someone on IRC in the coming days

I catched a sponsor for you. :slight_smile:

But since this is a backport of a higher version, Mattia prefers a minimal patch based on the 38-2 source. I think this is what he would like to see:

diff -ru dash-to-panel-38.orig/debian/changelog dash-to-panel-38/debian/changelog
--- dash-to-panel-38.orig/debian/changelog	2020-08-19 11:51:57.000000000 +0200
+++ dash-to-panel-38/debian/changelog	2020-09-04 20:38:09.095773732 +0200
@@ -1,3 +1,10 @@
+gnome-shell-extension-dash-to-panel (38-2~ubuntu20.04.1) focal; urgency=medium
+
+  * Backport from groovy as an SRU (LP: #1892245)
+  * debian/control: Change debhelper-compat to 12
+
+ -- Fabio Colella <fcole90@gmail.com>  Wed, 02 Sep 2020 16:19:21 +0300
+
 gnome-shell-extension-dash-to-panel (38-2) unstable; urgency=medium
 
   * Apply patch to fix overview bug (Closes: #968613)
diff -ru dash-to-panel-38.orig/debian/control dash-to-panel-38/debian/control
--- dash-to-panel-38.orig/debian/control	2020-07-15 12:22:31.000000000 +0200
+++ dash-to-panel-38/debian/control	2020-09-04 20:36:34.255297198 +0200
@@ -1,8 +1,9 @@
 Source: gnome-shell-extension-dash-to-panel
 Section: gnome
 Priority: optional
-Maintainer: Jonathan Carter <jcc@debian.org>
-Build-Depends: debhelper-compat (= 13), libglib2.0-bin, zip
+Maintainer: Ubuntu Developers <ubuntu-devel-discuss@lists.ubuntu.com>
+XSBC-Original-Maintainer: Jonathan Carter <jcc@debian.org>
+Build-Depends: debhelper-compat (= 12), libglib2.0-bin, zip
 Standards-Version: 4.5.0
 Rules-Requires-Root: no
 Homepage: https://github.com/jderose9/dash-to-panel

One detail is that the version string must be lower than the groovy version. The ~ character fixes that.

And, as you realized, debhelper-compat (=13) doesn’t work on focal. It’s appropriate to mention that change in debian/changelog. I also changed the maintainer, but that kind of change is usually not mentioned in debian/changelog.

So if you agree, I would suggest that you attach this minimal patch to the bug report (but keep the other patch too, since it contains all the differences compared to the current focal source, and that’s useful for those who will review it).

1 Like

Thank you very much for everything, I just submitted the patch you suggested :blush:

@ian-weisser: This topic isn’t placed in an optimal category. Can you please move it to the documentation -> contribute category, where it probably fits better.

1 Like

@fcole90: Saw Robie’s comment at the bug report. Looks like you’d better try at least the single commit way (via a patch in debian/patches/).

He has been very convincing in his arguments, I’m going to check what you suggest, thanks :blush:

I created this patch with quilt and then manually added DEP-3 headers. However when I try to make debuild -S it fails. However, quilt understands the diff without complaining.

Description: Fixes bug #1892245
 * Applies upstream fix: https://github.com/home-sweet-gnome/dash-to-panel/commit/eff0322dc188d36913048e8adc66329952437fcd
 * Applies upstream fix: https://github.com/home-sweet-gnome/dash-to-panel/commit/ed00ae61ba5c81ceec6e5bb9f04afa8272fac13a
 * Add newline at the end of the file
Bug: https://github.com/home-sweet-gnome/dash-to-panel/issues/1134
Bug-Ubuntu: https://bugs.launchpad.net/bugs/1892245
Bug-Debian: https://bugs.debian.org/%23968613
Forwarded: not-needed
Author: Fabio Colella <fcole90@gmail.com>
Last-Update: 2020-09-10

--- a/panelManager.js
+++ b/panelManager.js
@@ -461,8 +461,16 @@
 
         this._workspacesViews.forEach(wv => Main.layoutManager.overviewGroup.add_actor(wv.actor));
 
-        this._updateWorkspacesFullGeometry();
-        this._updateWorkspacesActualGeometry();
+        if (this._syncWorkspacesFullGeometry) {
+        //gnome-shell 3.36.4
+            if (this._fullGeometry)
+                this._syncWorkspacesFullGeometry();
+            if (this._actualGeometry)
+                this._syncWorkspacesActualGeometry();
+        } else {
+            this._updateWorkspacesFullGeometry();
+            this._updateWorkspacesActualGeometry();
+        }
     },
 
     _newGetShowAppsButton: function() {
@@ -723,3 +731,4 @@
     this._resize();
     this._oldOpen();
 }
+

Output:

$ debuild -S
 dpkg-buildpackage -us -uc -ui -S
dpkg-buildpackage: info: source package gnome-shell-extension-dash-to-panel
dpkg-buildpackage: info: source version 31-1~ubuntu20.04.1
dpkg-buildpackage: info: source distribution focal
dpkg-buildpackage: info: source changed by Fabio Colella <fcole90@gmail.com>
 dpkg-source --before-build .
 debian/rules clean
dh clean
   dh_auto_clean
	make -j12 clean
make[1]: Entering directory '/home/fabio/tmp/dash-to-panel-cherry-fix/patched/gnome-shell-extension-dash-to-panel-31'
fatal: not a git repository (or any of the parent directories): .git
fatal: not a git repository (or any of the parent directories): .git
rm -f ./schemas/gschemas.compiled
make[1]: Leaving directory '/home/fabio/tmp/dash-to-panel-cherry-fix/patched/gnome-shell-extension-dash-to-panel-31'
   dh_clean
 dpkg-source -b .
dpkg-source: info: using source format '3.0 (quilt)'
dpkg-source: info: building gnome-shell-extension-dash-to-panel using existing ./gnome-shell-extension-dash-to-panel_31.orig.tar.gz
dpkg-source: info: using patch list from debian/patches/series
patching file panelManager.js
Hunk #2 FAILED at 731.
1 out of 2 hunks FAILED
dpkg-source: info: the patch has fuzz which is not allowed, or is malformed
dpkg-source: info: if patch 'dash-to-panel-focal-fix.diff' is correctly applied by quilt, use 'quilt refresh' to update it
dpkg-source: error: LC_ALL=C patch -t -F 0 -N -p1 -u -V never -E -b -B .pc/dash-to-panel-focal-fix.diff/ --reject-file=- < gnome-shell-extension-dash-to-panel-31.orig.dpODoo/debian/patches/dash-to-panel-focal-fix.diff subprocess returned exit status 1
dpkg-buildpackage: error: dpkg-source -b . subprocess returned exit status 2
debuild: fatal error at line 1182:
dpkg-buildpackage -us -uc -ui -S failed
$ quilt refresh
Patch debian/patches/dash-to-panel-focal-fix.diff is unchanged
$ quilt push -a
File series fully applied, ends at patch debian/patches/dash-to-panel-focal-fix.diff

Can you give me some hints? :thinking: Line is 731 close to the end of the file, as you can see at the end of the diff

I already checked common means for removing possible fuzz: https://wiki.debian.org/Projects/DebSrc3.0#I_converted_my_package_but_it_fails_to_build_or_fails_to_unpack_on_all_buildds

Change the second chunk to look like this:

@@ -722,4 +730,5 @@ function _newLookingGlassOpen() {
 
     this._resize();
     this._oldOpen();
-}
\ No newline at end of file
+}
+

Not sure why you do that, though. :wink:

Also, change the version string to 31-1ubuntu20.04.1 (it must be higher than 31-1).

Oh, thanks, so it wants that every non-consecutive change is in that form, does it? It’s weird, as the diff was produced by quilt, so I expected it would have produced well-formed diffs :man_shrugging:

BTW, I made the change because I thought it mattered, as I got warnings about it

dpkg-source: warning: file gnome-shell-extension-dash-to-panel-31/panelManager.js has no final newline (either original or modified version)

I also needed to add

--- a/panelManager.js
+++ b/panelManager.js

at the beginning to make it accept it

I don’t have much to say about that. I usually create patches with diff or git-diff, and then it looks like that.

I see. Maybe a trailing newline is advisable in JavaScript then.

But that was already there, wasn’t it? Weird.

As regards the changelog, the version string is still wrong. You should not use the ~ character this time.

Otherwise it LGTM. Btw, does it work? :slight_smile:

Ouch, I quickly changed the version name :smiley: I didn’t notice that ~ was no longer there. So, is that only used for backports? :blush:

Indeed, but dpkg-source complained in the first line of the second chunk that it was expecting to see --- so I added that and it stopped complaining :man_shrugging:

Now the diff is on launchpad, and I asked Mattia to upload it again. As for the package, yes, I’m using the version I just patched and all seem fine :slight_smile::+1:

The ~ character is there to denote a lower version according to the dpkg --compare-versions logic than the part of the string preceding it. So yes, it’s typically used for backports.

Great!

1 Like