Bug#893448: please add a chromium-source binary package
[Filip Hanes] > Hi, > I'm new maintainer of casparcg-server after pere. And I am very happy to have a replacement who actually use the package. :) The package is also moved under the Debian Multimedia umbrella, allowing more people to particiate. :) >> 1) Chromium adds a chromium-source binary package, with the >> understanding that whoever packages CEF will keep it out of stable > > Could we try this option 1) to make some progress at least in unstable > and testing and later with more experience see if we can continue to > other option? I suggest you give it a go locally, and see if you can get it working, as well as report your progress on #debian-multimedia, to see if others can help. :) -- Happy hacking Petter Reinholdtsen
Bug#893448: please add a chromium-source binary package
Hi, I'm new maintainer of casparcg-server after pere. > 1) Chromium adds a chromium-source binary package, with the understanding > that whoever packages CEF will keep it out of stable Could we try this option 1) to make some progress at least in unstable and testing and later with more experience see if we can continue to other option? -- Filip Hanes
Bug#893448: please add a chromium-source binary package
On Mon, 15 Oct 2018 23:00:23 +0200 =?UTF-8?Q?Moritz_M=C3=BChlenhoff?= wrote: > On Mon, Oct 15, 2018 at 10:41:25PM +0200, Steinar H. Gunderson wrote: > > On Mon, Oct 15, 2018 at 10:33:11PM +0200, Moritz Muehlenhoff wrote: > > > Ultimately this is up for Michael to decide, as he's dealing with Chromium > > > updates single-handedly. > > > > Agreed. > > > > > Personally I have no reservations against this entering unstable, but this doesn't sound > > > like something that should enter a stable release. If the Chrome development team with > > > it's hundreds of full time developers can't/wont commit to a stable interface for these > > > kinds of extensions, why should we kludge around this with our sparse resources? > > > > I guess the answer is because software wants it. :-) > > > > CEF exists precisely to be an API-stable interface for this; it's unfortunate > > that Chrome doesn't care enough, but CEF is meant to be that layer, and seems > > to be doing pretty well (judging by the amount of software that uses it). > > But our current infrastructure for security.debian.org doesn't scale for this > kind of API whack-a-mole. Any update to unbreak CEF after Chromium major releases > would need to go through the security team and sucks up our time which is more > usefully spend elsewhere. > > Realistically, to make this would we'd need $SOMEONE to implement #817285, if > that were in place we could simply push an ACL change and enable you take care > of CEF updates in buster-security on your own. > > Cheers, > Moritz > > I'm just coming up to speed on this (I'd never heard of CEF before, but having a stable API for embedding chromium seems very sensible). I can see a few different options here. I'm just going to document for posterity as a followup to #893448. Please chime in if there's anything else I should be considering. 1) Chromium adds a chromium-source binary package, with the understanding that whoever packages CEF will keep it out of stable; or perhaps kept out of stable by chromium itself, if chromium doesn't ship in bookworm. It could be available in fasttrack or something, but we won't make any attempt to have official mechanisms for CEF stable updates. Pros: minimal effort on my part, no additional overhead by release/security teams. Cons: packages that want to build against CEF (obs-studio, casparcg-server, and possibly others) will be forced to choose between optionally building against it but staying out of stable releases, or splitting their source packages up into one that gets to migrate to stable and one that doesn't. 2) Chromium adds a chromium-source binary package, whoever packages CEF joins the chromium team (*waves to Sesse & pere*), and we work together to push stable releases of chromium and CEF in a way that the security team deems least objectionable (again, assuming chromium ships in bookworm). Pros: packages that want to depend on CEF in stable can safely do so. Cons: more effort on my part, more complicated testing migrations, and the security team has already said that they don't like this idea making it a non-starter until #817285 gets fixed. Also, it's generally just kind of annoying to have two separate packages so tightly bound together by an unstable API/ABI. 3) Chromium source package adds CEF to its source package. Chromium builds CEF along with itself, and supplies a set of libcef-dev/libcef1 binary packages. Whoever wanted to package CEF joins the chromium team and keeps the packaging updated in the chromium-team git repo. Pros: no additional work needed by the security team. Packages that want to depend on CEF in stable can safely do so. Cons: more effort on my part (or maybe less if the team member starts helping w/ general chromium stuff?), chromium will have to worry about CEF-depending packages during testing migrations, already too-long chromium builds take longer, and we could run into a situation where CEF upstream disappears and we're stuck without updates (which could be potentially disasterous for bookworm stable updates). And of course, I haven't actually tried doing a CEF build so I don't know how feasible embedding it into the src:chromium package is. I don't have strong opinions either way, but if someone wanted to experiment with implementing #3, I'd be open to considering it.
Bug#893448: please add a chromium-source binary package
For the record, I registered WNPP https://bugs.debian.org/915400 > asking for CEF before I was made aware of this discussion. -- Happy hacking Petter Reinholdtsen
Bug#893448: please add a chromium-source binary package
On Mon, Oct 15, 2018 at 10:41:25PM +0200, Steinar H. Gunderson wrote: > On Mon, Oct 15, 2018 at 10:33:11PM +0200, Moritz Muehlenhoff wrote: > > Ultimately this is up for Michael to decide, as he's dealing with Chromium > > updates single-handedly. > > Agreed. > > > Personally I have no reservations against this entering unstable, but this > > doesn't sound > > like something that should enter a stable release. If the Chrome > > development team with > > it's hundreds of full time developers can't/wont commit to a stable > > interface for these > > kinds of extensions, why should we kludge around this with our sparse > > resources? > > I guess the answer is because software wants it. :-) > > CEF exists precisely to be an API-stable interface for this; it's unfortunate > that Chrome doesn't care enough, but CEF is meant to be that layer, and seems > to be doing pretty well (judging by the amount of software that uses it). But our current infrastructure for security.debian.org doesn't scale for this kind of API whack-a-mole. Any update to unbreak CEF after Chromium major releases would need to go through the security team and sucks up our time which is more usefully spend elsewhere. Realistically, to make this would we'd need $SOMEONE to implement #817285, if that were in place we could simply push an ACL change and enable you take care of CEF updates in buster-security on your own. Cheers, Moritz
Bug#893448: please add a chromium-source binary package
On Mon, Oct 15, 2018 at 10:33:11PM +0200, Moritz Muehlenhoff wrote: > Ultimately this is up for Michael to decide, as he's dealing with Chromium > updates single-handedly. Agreed. > Personally I have no reservations against this entering unstable, but this > doesn't sound > like something that should enter a stable release. If the Chrome development > team with > it's hundreds of full time developers can't/wont commit to a stable interface > for these > kinds of extensions, why should we kludge around this with our sparse > resources? I guess the answer is because software wants it. :-) CEF exists precisely to be an API-stable interface for this; it's unfortunate that Chrome doesn't care enough, but CEF is meant to be that layer, and seems to be doing pretty well (judging by the amount of software that uses it). /* Steinar */ -- Homepage: https://www.sesse.net/
Bug#893448: please add a chromium-source binary package
On Mon, Oct 15, 2018 at 11:00:24AM -0700, Jonathan Nieder wrote: > Hi, > > Emilio Pozuelo Monfort wrote: > Michael Gilbert wrote: > > > Major updates to chromium in stable have so far been contingent on it > > being a leaf package, where there is no chance for it to break > > anything else. Adding CEF as a reverse dependency would change that. > > ^^ > > > On 15/10/2018 19:19, Steinar H. Gunderson wrote: > >> On Mon, Jul 02, 2018 at 12:29:15PM +0200, Steinar H. Gunderson wrote: > > >>> Release team, for the short recap: Would it be acceptable to have chromium > >>> provide a chromium-source binary package, and then package CEF (Chromium > >>> Embedded Framework) Build-Depending on that package, and then have other > >>> packages depend on CEF? CEF aims to provide a stable API/ABI on top of > >>> Chromium for other software to use, but needs updating whenever Chromium > >>> releases a new major version. See #893448 for some more details. > >> > >> Ping :-) Release team, do you want to weigh in? If nothing else, perhaps we > >> could add a CEF package in unstable only (ie., with a testing blocker bug) > >> for the time being. > >> > >> FWIW, I've updated my CEF packages to CEF/Chromium 69; all that was > >> required was > >> to patch out installation of Swiftshader (since Debian's packages now > >> disable it). > > > > I'm not sure we (RT) need to make any decision here. > > > > Adding a chromium-src for other packages to build against is not special in > > any > > way, we don't approve this for other packages. > > However, you do have some say in whether a package is able to have > non-trivial updates in stable. Can we infer from your reply that > you're still okay with this for Chromium even if CEF relies on it, > provided security team is okay with it? > > > As for the security support concerns, that's up to the security team. > > Therefore cc-ing security team. Ultimately this is up for Michael to decide, as he's dealing with Chromium updates single-handedly. Personally I have no reservations against this entering unstable, but this doesn't sound like something that should enter a stable release. If the Chrome development team with it's hundreds of full time developers can't/wont commit to a stable interface for these kinds of extensions, why should we kludge around this with our sparse resources? This is rather that kind of wacky not-really-suitable-for-stable-but-still-kinda-nice stuff we should have PPAs for. Cheers, Moritz
Bug#893448: please add a chromium-source binary package
Hi, Emilio Pozuelo Monfort wrote: Michael Gilbert wrote: > Major updates to chromium in stable have so far been contingent on it > being a leaf package, where there is no chance for it to break > anything else. Adding CEF as a reverse dependency would change that. ^^ > On 15/10/2018 19:19, Steinar H. Gunderson wrote: >> On Mon, Jul 02, 2018 at 12:29:15PM +0200, Steinar H. Gunderson wrote: >>> Release team, for the short recap: Would it be acceptable to have chromium >>> provide a chromium-source binary package, and then package CEF (Chromium >>> Embedded Framework) Build-Depending on that package, and then have other >>> packages depend on CEF? CEF aims to provide a stable API/ABI on top of >>> Chromium for other software to use, but needs updating whenever Chromium >>> releases a new major version. See #893448 for some more details. >> >> Ping :-) Release team, do you want to weigh in? If nothing else, perhaps we >> could add a CEF package in unstable only (ie., with a testing blocker bug) >> for the time being. >> >> FWIW, I've updated my CEF packages to CEF/Chromium 69; all that was required >> was >> to patch out installation of Swiftshader (since Debian's packages now >> disable it). > > I'm not sure we (RT) need to make any decision here. > > Adding a chromium-src for other packages to build against is not special in > any > way, we don't approve this for other packages. However, you do have some say in whether a package is able to have non-trivial updates in stable. Can we infer from your reply that you're still okay with this for Chromium even if CEF relies on it, provided security team is okay with it? > As for the security support concerns, that's up to the security team. Therefore cc-ing security team. Thanks, Jonathan
Bug#893448: please add a chromium-source binary package
On 15/10/2018 19:19, Steinar H. Gunderson wrote: > On Mon, Jul 02, 2018 at 12:29:15PM +0200, Steinar H. Gunderson wrote: >> On Mon, Jun 04, 2018 at 12:17:21AM +0200, Steinar H. Gunderson wrote: Major updates to chromium in stable have so far been contingent on it being a leaf package, where there is no chance for it to break anything else. Adding CEF as a reverse dependency would change that. This is more of a question for the release team, it would need their approval. >>> Agreed. >> Release team, for the short recap: Would it be acceptable to have chromium >> provide a chromium-source binary package, and then package CEF (Chromium >> Embedded Framework) Build-Depending on that package, and then have other >> packages depend on CEF? CEF aims to provide a stable API/ABI on top of >> Chromium for other software to use, but needs updating whenever Chromium >> releases a new major version. See #893448 for some more details. > > Ping :-) Release team, do you want to weigh in? If nothing else, perhaps we > could add a CEF package in unstable only (ie., with a testing blocker bug) > for the time being. > > FWIW, I've updated my CEF packages to CEF/Chromium 69; all that was required > was > to patch out installation of Swiftshader (since Debian's packages now disable > it). I'm not sure we (RT) need to make any decision here. Adding a chromium-src for other packages to build against is not special in any way, we don't approve this for other packages. As for the security support concerns, that's up to the security team. Cheers, Emilio
Bug#893448: please add a chromium-source binary package
On Mon, Jul 02, 2018 at 12:29:15PM +0200, Steinar H. Gunderson wrote: > On Mon, Jun 04, 2018 at 12:17:21AM +0200, Steinar H. Gunderson wrote: >>> Major updates to chromium in stable have so far been contingent on it >>> being a leaf package, where there is no chance for it to break >>> anything else. Adding CEF as a reverse dependency would change that. >>> >>> This is more of a question for the release team, it would need their >>> approval. >> Agreed. > Release team, for the short recap: Would it be acceptable to have chromium > provide a chromium-source binary package, and then package CEF (Chromium > Embedded Framework) Build-Depending on that package, and then have other > packages depend on CEF? CEF aims to provide a stable API/ABI on top of > Chromium for other software to use, but needs updating whenever Chromium > releases a new major version. See #893448 for some more details. Ping :-) Release team, do you want to weigh in? If nothing else, perhaps we could add a CEF package in unstable only (ie., with a testing blocker bug) for the time being. FWIW, I've updated my CEF packages to CEF/Chromium 69; all that was required was to patch out installation of Swiftshader (since Debian's packages now disable it). /* Steinar */ -- Homepage: https://www.sesse.net/
Bug#893448: please add a chromium-source binary package
On Mon, Jun 04, 2018 at 12:17:21AM +0200, Steinar H. Gunderson wrote: >> Major updates to chromium in stable have so far been contingent on it >> being a leaf package, where there is no chance for it to break >> anything else. Adding CEF as a reverse dependency would change that. >> >> This is more of a question for the release team, it would need their >> approval. > Agreed. I realize I should have Cc-ed debian-release :-) Release team, for the short recap: Would it be acceptable to have chromium provide a chromium-source binary package, and then package CEF (Chromium Embedded Framework) Build-Depending on that package, and then have other packages depend on CEF? CEF aims to provide a stable API/ABI on top of Chromium for other software to use, but needs updating whenever Chromium releases a new major version. See #893448 for some more details. /* Steinar */ -- Homepage: https://www.sesse.net/
Bug#893448: please add a chromium-source binary package
On Sun, Jun 03, 2018 at 06:08:53PM -0400, Michael Gilbert wrote: > I am more concerned about major version updates. I anticipate nearly > each one will cause CEF to fail to build from source, causing new RC > bugs often in the stable release. Yes, CEF will definitely need upgrading on major version updates. That's the bad news -- the good news is that CEF upstream is usually very much on top of that, doing the necessary changes well before a version hits the stable channel. > Major updates to chromium in stable have so far been contingent on it > being a leaf package, where there is no chance for it to break > anything else. Adding CEF as a reverse dependency would change that. > > This is more of a question for the release team, it would need their approval. Agreed. /* Steinar */ -- Homepage: https://www.sesse.net/
Bug#893448: please add a chromium-source binary package
On Sun, May 27, 2018 at 3:36 AM, Steinar H. Gunderson wrote: > On Sat, May 26, 2018 at 11:28:29PM -0400, Michael Gilbert wrote: >> Are you intending CEF to make it into a stable release? > > Yes. > >> Since chromium's source is updated every few weeks for security updates, >> won't CEF need to be updated just as often? > > Yes. CEF generally follows Chromium fairly closely (support for a Chromium > branch begins when it enters the beta channel, and ends when it exits the > stable channel). > >> If so, I'm not sure that will be supportable over the lifetime of a stable >> release. > > It's an open question to what degree we can give it security support, indeed. > The intention is for this to go through binNMUs for minor Chromium versions; > you'd have to actually upgrade CEF when major version bumps happen, which > means CEF security support would probably lag a week or two behind Chromium > security support in such cases. I am more concerned about major version updates. I anticipate nearly each one will cause CEF to fail to build from source, causing new RC bugs often in the stable release. Major updates to chromium in stable have so far been contingent on it being a leaf package, where there is no chance for it to break anything else. Adding CEF as a reverse dependency would change that. This is more of a question for the release team, it would need their approval. Best wishes, Mike
Bug#893448: please add a chromium-source binary package
On Sat, Apr 28, 2018 at 06:54:32PM +0200, Steinar H. Gunderson wrote: >> As mentioned on pkg-chromium-browser@, it would be useful if chromium-browser >> shipped a chromium-browser source package; it would allow packaging and >> building >> CEF (Chromium Embedded Framework) against Debian's (patched) sources instead >> of >> off some random git checkout. I've added a patch. > Patch updated for Chromium 66 (trivial; really just unfuzzed). Chromium 67 was similarly trivial, so I didn't bother updating. CEF required a tiny bit more work (Widevine no longer seems to be supported), but was fairly easy, too. New CEF packages (source and binary) at http://storage.sesse.net/cef/ /* Steinar */ -- Homepage: https://www.sesse.net/
Bug#893448: please add a chromium-source binary package
On Sat, May 26, 2018 at 11:28:29PM -0400, Michael Gilbert wrote: > Are you intending CEF to make it into a stable release? Yes. > Since chromium's source is updated every few weeks for security updates, > won't CEF need to be updated just as often? Yes. CEF generally follows Chromium fairly closely (support for a Chromium branch begins when it enters the beta channel, and ends when it exits the stable channel). > If so, I'm not sure that will be supportable over the lifetime of a stable > release. It's an open question to what degree we can give it security support, indeed. The intention is for this to go through binNMUs for minor Chromium versions; you'd have to actually upgrade CEF when major version bumps happen, which means CEF security support would probably lag a week or two behind Chromium security support in such cases. Note that in many of the use cases CEF covers, you only run trusted code. In particular, in the two possible downstream users in Debian that I know of (nageru and obs-browser), Chromium is simply used as a rendering engine for animation/graphics, not presented as a browser with a UI. Thus, it wouldn't be a big loss to declare end of CEF security support if we run into insurmountable troubles upgrading it in stable. /* Steinar */ -- Homepage: https://www.sesse.net/
Bug#893448: please add a chromium-source binary package
control: tag -1 moreinfo On Sun, Mar 18, 2018 at 11:39:22PM +0100, Steinar H. Gunderson wrote: > As mentioned on pkg-chromium-browser@, it would be useful if chromium-browser > shipped a chromium-browser source package; it would allow packaging and > building > CEF (Chromium Embedded Framework) against Debian's (patched) sources instead > of > off some random git checkout. I've added a patch. Are you intending CEF to make it into a stable release? Since chromium's source is updated every few weeks for security updates, won't CEF need to be updated just as often? If so, I'm not sure that will be supportable over the lifetime of a stable release. Best wishes, Mike
Bug#893448: please add a chromium-source binary package
On Sun, Mar 18, 2018 at 11:39:22PM +0100, Steinar H. Gunderson wrote:
> As mentioned on pkg-chromium-browser@, it would be useful if chromium-browser
> shipped a chromium-browser source package; it would allow packaging and
> building
> CEF (Chromium Embedded Framework) against Debian's (patched) sources instead
> of
> off some random git checkout. I've added a patch.
Patch updated for Chromium 66 (trivial; really just unfuzzed).
There's an issue in that chromium/BUILD.gn:749 has an assignment which
according to gn “had no effect”, though.
/* Steinar */
--
Homepage: https://www.sesse.net/
diff -Nru chromium-browser-66.0.3359.117/debian/changelog chromium-browser-66.0.3359.117/debian/changelog
--- chromium-browser-66.0.3359.117/debian/changelog 2018-04-26 03:27:39.0 +0200
+++ chromium-browser-66.0.3359.117/debian/changelog 2018-04-28 18:15:53.0 +0200
@@ -1,3 +1,10 @@
+chromium-browser (66.0.3359.117-1+nmu1) UNRELEASED; urgency=medium
+
+ * Non-maintainer upload.
+ * Add a chromium-source binary package.
+
+ -- Steinar H. Gunderson Sat, 28 Apr 2018 18:15:53 +0200
+
chromium-browser (66.0.3359.117-1) unstable; urgency=medium
* New upstream stable release.
diff -Nru chromium-browser-66.0.3359.117/debian/chromium-source.install chromium-browser-66.0.3359.117/debian/chromium-source.install
--- chromium-browser-66.0.3359.117/debian/chromium-source.install 1970-01-01 01:00:00.0 +0100
+++ chromium-browser-66.0.3359.117/debian/chromium-source.install 2018-04-28 18:14:18.0 +0200
@@ -0,0 +1,3 @@
+out/chromium-src.tar.xz /usr/src/chromium
+out/chromium-src.flags /usr/src/chromium
+
diff -Nru chromium-browser-66.0.3359.117/debian/control chromium-browser-66.0.3359.117/debian/control
--- chromium-browser-66.0.3359.117/debian/control 2018-04-23 01:48:23.0 +0200
+++ chromium-browser-66.0.3359.117/debian/control 2018-04-28 18:14:18.0 +0200
@@ -189,3 +189,12 @@
.
This package contains resources that are in common to different chromium
packages.
+
+Package: chromium-source
+Architecture: all
+Recommends: xz-utils
+Description: web browser - source code
+ Web browser that aims to build a safer, faster, and more stable internet
+ browsing experience.
+ .
+ This package contains the patched source code used to build the packages.
diff -Nru chromium-browser-66.0.3359.117/debian/rules chromium-browser-66.0.3359.117/debian/rules
--- chromium-browser-66.0.3359.117/debian/rules 2018-04-09 00:07:41.0 +0200
+++ chromium-browser-66.0.3359.117/debian/rules 2018-04-28 18:14:18.0 +0200
@@ -129,6 +129,14 @@
./out/Release/gn gen out/Release --args="$(defines)"
ninja -j$(njobs) -C out/Release packed_resources
rm -f out/Release/locales/en-US.pak
+ echo "$(defines)" | sed 's/host_cpu=[^ ]*//' > $(CURDIR)/out/chromium-src.flags
+ find . '(' -path ./debian -or -path ./out ')' -prune -or -print0 | \
+ LC_ALL=C sort -z | \
+ tar -c -vv -J --null --no-recursion --transform 's,^\./,chromium/,' -T - \
+ --mode=go=rX,u+rw,a-s \
+ --clamp-mtime --mtime "@$(SOURCE_DATE_EPOCH)" \
+ --owner=root --group=root --numeric-owner \
+ -f $(CURDIR)/out/chromium-src.tar.xz
override_dh_auto_install-arch:
dh_auto_install
Bug#893448: please add a chromium-source binary package
Source: chromium-browser
Version: 65.0.3325.146-4
Severity: wishlist
Tags: patch
Hi,
As mentioned on pkg-chromium-browser@, it would be useful if chromium-browser
shipped a chromium-browser source package; it would allow packaging and building
CEF (Chromium Embedded Framework) against Debian's (patched) sources instead of
off some random git checkout. I've added a patch.
-- System Information:
Debian Release: 9.4
APT prefers stable-debug
APT policy: (500, 'stable-debug'), (500, 'proposed-updates'), (500,
'stable'), (500, 'oldstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 4.16.0-rc1 (SMP w/40 CPU cores)
Locale: LANG=en_DK.UTF-8, LC_CTYPE=en_DK.UTF-8 (charmap=UTF-8),
LANGUAGE=en_NO:en_US:en_GB:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
diff -Nru chromium-browser-65.0.3325.146/debian/changelog
chromium-browser-65.0.3325.146/debian/changelog
--- chromium-browser-65.0.3325.146/debian/changelog 2018-03-05
02:26:31.0 +0100
+++ chromium-browser-65.0.3325.146/debian/changelog 2018-03-11
00:43:35.0 +0100
@@ -1,3 +1,10 @@
+chromium-browser (65.0.3325.146-1.1) UNRELEASED; urgency=medium
+
+ * Non-maintainer upload.
+ * Add a chromium-source binary package.
+
+ -- Steinar H. Gunderson Sun, 11 Mar 2018 00:43:35 +0100
+
chromium-browser (65.0.3325.146-1) unstable; urgency=medium
* New upstream stable release release.
diff -Nru chromium-browser-65.0.3325.146/debian/chromium-source.install
chromium-browser-65.0.3325.146/debian/chromium-source.install
--- chromium-browser-65.0.3325.146/debian/chromium-source.install
1970-01-01 01:00:00.0 +0100
+++ chromium-browser-65.0.3325.146/debian/chromium-source.install
2018-03-09 22:47:59.0 +0100
@@ -0,0 +1,3 @@
+out/chromium-src.tar.xz /usr/src/chromium
+out/chromium-src.flags /usr/src/chromium
+
diff -Nru chromium-browser-65.0.3325.146/debian/control
chromium-browser-65.0.3325.146/debian/control
--- chromium-browser-65.0.3325.146/debian/control 2018-03-05
02:26:31.0 +0100
+++ chromium-browser-65.0.3325.146/debian/control 2018-03-09
22:46:54.0 +0100
@@ -189,3 +189,12 @@
.
This package contains resources that are in common to different chromium
packages.
+
+Package: chromium-source
+Architecture: all
+Recommends: xz-utils
+Description: web browser - source code
+ Web browser that aims to build a safer, faster, and more stable internet
+ browsing experience.
+ .
+ This package contains the patched source code used to build the packages.
diff -Nru chromium-browser-65.0.3325.146/debian/rules
chromium-browser-65.0.3325.146/debian/rules
--- chromium-browser-65.0.3325.146/debian/rules 2018-03-05 02:26:31.0
+0100
+++ chromium-browser-65.0.3325.146/debian/rules 2018-03-10 14:58:29.0
+0100
@@ -113,6 +113,14 @@
./out/Release/gn gen out/Release --args="$(defines)"
ninja $(njobs) -C out/Release packed_resources
rm -f out/Release/locales/en-US.pak
+ echo "$(defines)" | sed 's/host_cpu=[^ ]*//' >
$(CURDIR)/out/chromium-src.flags
+ find . '(' -path ./debian -or -path ./out ')' -prune -or -print0 | \
+ LC_ALL=C sort -z | \
+ tar -c -vv -J --null --no-recursion --transform
's,^\./,chromium/,' -T - \
+ --mode=go=rX,u+rw,a-s \
+ --clamp-mtime --mtime "@$(SOURCE_DATE_EPOCH)" \
+ --owner=root --group=root --numeric-owner \
+ -f $(CURDIR)/out/chromium-src.tar.xz
override_dh_auto_install-arch:
dh_auto_install
