Bug#1005701: ITP: python-untangle -- Convert XML to a Python object
Package: wnpp Severity: wishlist Owner: Julian Gilbey X-Debbugs-Cc: debian-devel@lists.debian.org, debian-pyt...@lists.debian.org * Package name: python-untangle Version : 1.1.1+git20200807.fb916a9 Upstream Author : Christian Stefanescu * URL : https://github.com/stchris/untangle * License : MIT Programming Lang: Python Description : Convert XML to a Python object Untangle has a very simple API for converting XML to a Python object: you just call the "parse" function on either a string, a filename or a URL. This package is used in the tests for pydevd, which I am currently working on packaging (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=933070). It will be maintained within the Debian Python Team. Best wishes, Julian
Re: chromium: Update to version 94.0.4606.61 (security-fixes)
On Sat, Feb 12, 2022 at 2:12 AM Andres Salomon wrote:
>
> On 2/11/22 06:18, Roger Shimizu wrote:
>
> > Dear Andres,
> >
> > Thanks for your work for chromium!
> >
> > On Mon, Jan 3, 2022 at 7:33 PM Andres Salomon wrote:
> I saw
> https://salsa.debian.org/dilinger/chromium/-/commit/5c05f430e192961527ec9a64bbaa64401dc14d95
> , but buster now also includes LLVM/clang 11 (it was introduced to
> support a more recent Rust toolchain needed for Firefox), so you
> might be reduce complexity here further:
> https://tracker.debian.org/pkg/llvm-toolchain-11
>
> It's in buster-proposed-updates since there hasn't been a point
> release since, but for the purposes of buster-security builds, it
> doesn't matter (they chroots have been modified to includen
> buster-proposed-updates temporarily):
> >>> Ah, very helpful, thanks! I'll give buster a try (just created
> >>> the 'v96-buster' branch). Between that and various backports, I think
> >>> we might be in good shape.
> >> Unfortunately it needs a newer nodejs than what's in buster, so I'll go
> >> back to focusing on bullseye & sid for now. :(
> > I tried to backport bullseye's v97 to buster, but error below occured.
> > I also tired the v96-buster branch from your salsa git repo, and got
> > similar error.
> >
> > So this is the error you mentioned above that buster's nodejs package
> > is too old for chromium?
> > Is it possible to use embed nodejs to workaround this issue?
> >
> > I also guess this might be related to incompatible between system's
> > nodejs and embed rollup binary.
> > Is it possible to add a patch to replace with system's rollup?
> >
> > Error from buster-backports pbuilder for bullseye's chromium v97:
> >
> > FAILED:
> > gen/third_party/devtools-frontend/src/front_end/panels/timeline/components/components.js
> > python3 ../../third_party/node/node.py
> > ../../third_party/devtools-frontend/src/node_modules/rollup/dist/bin/rollup
> > --silent --config
> > ../../third_party/devtools-frontend/src/scripts/build/rollup.config.js
> > --input
> > gen/third_party/devtools-frontend/src/front_end/panels/timeline/components/components.prebundle.js
> > --file
> > gen/third_party/devtools-frontend/src/front_end/panels/timeline/components/components.js
> > --configDCHECK
> > Traceback (most recent call last):
> >File "../../third_party/node/node.py", line 36, in
> > RunNode(sys.argv[1:])
> >File "../../third_party/node/node.py", line 31, in RunNode
> > raise RuntimeError('%s failed: %s' % (cmd, stderr))
> > RuntimeError: ['/usr/bin/nodejs',
> > '../../third_party/devtools-frontend/src/node_modules/rollup/dist/bin/rollup',
> > '--silent', '--config',
> > '../../third_party/devtools-frontend/src/scripts/build/rollup.config.js',
> > '--input',
> > 'gen/third_party/devtools-frontend/src/front_end/panels/timeline/components/components.prebundle.js',
> > '--file',
> > 'gen/third_party/devtools-frontend/src/front_end/panels/timeline/components/components.js',
> > '--configDCHECK'] failed: b'[!] (plugin minify-html-template-literals)
> > TypeError: result.matchAll is not a
> > function\ngen/third_party/devtools-frontend/src/front_end/panels/timeline/components/WebVitalsTimeline.js\nTypeError:
> > result.matchAll is not a function\nat Object.minifyHTML
> > (/build/chromium-97.0.4692.99/third_party/devtools-frontend/src/node_modules/minify-html-literals/src/strategy.ts:145:41)\n
> > at Object.minifyHTML
> > (/build/chromium-97.0.4692.99/third_party/devtools-frontend/src/scripts/build/rollup.config.js:80:37)\n
> > at templates.forEach.template
> > (/build/chromium-97.0.4692.99/third_party/devtools-frontend/src/node_modules/minify-html-literals/src/minifyHTMLLiterals.ts:322:24)\n
> > at Array.forEach ()\nat Object.minifyHTMLLiterals
> > (/build/chromium-97.0.4692.99/third_party/devtools-frontend/src/node_modules/minify-html-literals/src/minifyHTMLLiterals.ts:297:13)\n
> > at Object.transform
> > (/build/chromium-97.0.4692.99/third_party/devtools-frontend/src/node_modules/rollup-plugin-minify-html-template-literals/dist/index.js:15:47)\n
> > at Promise.resolve.then
> > (/build/chromium-97.0.4692.99/third_party/devtools-frontend/src/node_modules/rollup/dist/shared/rollup.js:20218:25)\n\n'
> >
> >
> > Cheers,
>
>
>
> Yes, that's the error. "String.matchAll is only available from Node.js
> 12.0 onwards", according to
> https://stackoverflow.com/questions/58558257/string-matchall-is-undefined
> , which also says that String.match is available. I didn't put any
> effort into working around it (either backporting a newer nodejs or
> replacing all String.matchAlls with something else), since I wanted to
> get chromium shipped for bullseye.
Thanks for your confirmation!
So we're on the same page.
I tried to backport nodejs 12 from bullseye to buster, but seems
nodejs 12 cannot coexist with nodejs 10, which means unless I backport
all the nodejs related packages,
Re: chromium: Update to version 94.0.4606.61 (security-fixes)
On Mon, 14 Feb 2022 at 01:06:11 +0900, Roger Shimizu wrote: > I also tried v98 based tree, and result is the same, same build error as > above. > My conclusion is that buster cannot get chromiium major version > updated easily (except flatpak way, of course). buster's version of flatpak does not have features that Chromium needs, so running Chromium as a Flatpak app on buster requires an updated flatpak from buster-backports. If the security and release teams want this to be possible, the only way that I think is realistic would be to take the bullseye version of flatpak, as backported into buster-backports, and copy it into buster via -proposed-updates or -security; that seems like it will be lower-risk than backporting arbitrary subsets of flatpak 1.10.x into (our fork of) flatpak 1.2.x. Chromium as a Flatpak app also requires access to unprivileged creation of user namespaces, which buster kernels don't allow by default. The bullseye version of bubblewrap enables this as part of the transition path to bullseye, but the buster-backports version does not. I could easily make the buster-backports version of bubblewrap enable unprivileged creation of user namespaces, but that doesn't seem like a "least astonishment" change for oldstable, so I'm not going to do that unless the security/stable-release teams ask me to. If we aren't willing to backport this sort of thing, which we have not historically been, then "don't use oldstable for desktop machines" seems like the only proportionate response - sorry, Flatpak can do a lot to facilitate app updates, but it isn't magic. smcv
Bug#1005707: ITP: pyqt6-sip -- runtime module for Python extensions using SIP
Package: wnpp Severity: wishlist Owner: Dmitry Shachnev X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: pyqt6-sip Version : 13.2.1 Upstream Author : Riverbank Computing Limited * URL : https://pypi.org/project/PyQt6-sip/ * License : SIP or GPL-2 or GPL-3 Programming Lang: C, C++, Python Description : runtime module for Python extensions using SIP SIP is a collection of tools that makes it very easy to create Python bindings for C and C++ libraries. PyQt6.sip is a runtime module, it is used by PyQt6 and other Python extension modules built with SIP. I am going to maintain it in the Debian Python Team: https://salsa.debian.org/python-team/packages/pyqt6-sip/ -- Dmitry Shachnev signature.asc Description: PGP signature
Bug#1005722: ITP: mistune0 -- Markdown parser for Python 3
Package: wnpp Severity: wishlist Owner: Pierre-Elliott Bécue X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: mistune0 Version : 0.8.4 Upstream Author : 2014-2018 Hsiaoming Yang * URL : https://github.com/lepture/mistune * License : BSD-3-Clause Programming Lang: Python3 Description : Markdown parser for Python 3 This is a source repackaging of mistune to allow a coexistence of mistune v 2 or more (in src:mistune) along with mistune 0.8.4 (in src:mistune0), as reverse dependencies won't be able to move forward as fast as one would expect. This repackaging is the result of a discussion in bug 1003567.
Including build metadata in packages
A while ago I noticed binutils had some embedded logs in one of it's packages, which included timing information about the test suite runs which will almost certainly have differences between the different builds, even on the exact same machine: https://bugs.debian.org/950585 My proposed patch removed the timing information and various other things, but was exactly the information wanted from these files, so was not an appropriate patch. It also became known that other key toolchain packages (e.g. gcc) also embed similar log files in the .deb packages... I have since found a few other packages that do similar things: https://tests.reproducible-builds.org/debian/issues/unstable/test_suite_logs_issue.html Obviously, this would interfere with any meaningful reproducible builds testing for any package that did something like this. Ideally metadata like this about a build should *not* be included in the .deb files themselves. I'll try to summarize and detail a bit some of the proposed strategies for resolving this issue: * output plaintext data to the build log Some of these log files are large (>13MB? per architecture, per package build) and would greatly benefit from compression... How large is too large for this approach to work? Relatively simple to implement (at least for plain text logs), but potentially stores a lot of data on the buildd infrastructure... * Selectively filter out known unreproducible files This adds complexity to the process of verification; you can't beat the simplicty of comparing checksums on two .deb files. With increased complexity comes increased opportunity for errors, as well as maintenance overhead. RPM packages, for example, embed signatures in the packages, and these need to be excluded for comparison. I vaguely recall at least one case where attempting something like this in the past and resulting in packages incorrectly being reported as reproducible when the filter was overly broad... Some nasty corner cases probably lurk down this approach... * Split build metadata into a separate .deb file Some of the similar problems of the previous, though maybe a little easier to get a reliable exclusion pattern? Wouldn't require huge toolchain changes. I would expect that such packages be not actually dependend on by any other packages, and *only* contain build metadata. Maybe named SOURCEPACKAGE-buildmetadata-unreproducible.deb ... or ? Not beautiful or elegant, but maybe actually achievable for bookworm release cycle? * Split build metadata into a separate file or archive Some of the debian-installer packages generate tarballs that are not .deb files and are included in the .changes files when uploading to the archive; making a similar generalized option for other packages to put build metadata into a separate artifact might be workable approach, although this would presumably require toolchain changes in dpkg and dak at the very least, and might take a couple release cycles, which is... well, debian. The possibility of bundling up .buildinfo files into this metadata too, while taking some changes in relevent dpkg, dak, etc. tooling, might in the long term be worth exploring. There was a relevent bug report in launchpad: https://bugs.launchpad.net/launchpad/+bug/1845159 This seems like the best long-term approach, but pretty much *only* a long-term approach... I'd really like to remove this hurdle to reproducible builds from some key packages like binutils and gcc, but also curious about a generalizable approach so each package needing something like this doesn't reinvent the wheel in incompatible ways... Curious to hear your thoughts! live well, vagrant p.s. please consider CCing me and/or reproducible-bui...@lists.alioth.debian.org, as I'm not subscribed to debian-devel. signature.asc Description: PGP signature
Re: chromium: Update to version 94.0.4606.61 (security-fixes)
2022, ഫെബ്രുവരി 13 9:36:11 PM IST, Roger Shimizu ൽ എഴുതി >On Sat, Feb 12, 2022 at 2:12 AM Andres Salomon wrote: >> Yes, that's the error. "String.matchAll is only available from Node.js >> 12.0 onwards", according to >> https://stackoverflow.com/questions/58558257/string-matchall-is-undefined >> , which also says that String.match is available. I didn't put any >> effort into working around it (either backporting a newer nodejs or >> replacing all String.matchAlls with something else), since I wanted to >> get chromium shipped for bullseye. > >Thanks for your confirmation! >So we're on the same page. >I tried to backport nodejs 12 from bullseye to buster, but seems >nodejs 12 cannot coexist with nodejs 10, which means unless I backport >all the nodejs related packages, which has quite a long list ... >That's out of my capacity, so I give up. I think using babel (already packaged) to transpile the js to run on nodejs 10 could be another option. -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
