Re: Anyone interested in python-pgpy?
Hi Sean, Sean Whitton writes: > Hello, > > On Sat 07 Dec 2024 at 02:27am -08, Xiyue Deng wrote: > >> Sean Whitton writes: >> >>> Hello, >>> >>> Many thanks, and nice documentation of the changes. >>> >>> If you'd like to send an MR or patch with a d/changelog entry, I can >>> upload the NMU credited to you. >>> >> >> Sounds good. I have the MR for updating d/changelog at [1]. I have a >> separate commit to finalize in case there are any comments to address. >> Please let me know if I should leave out the finalization instead. >> Thanks! > > No, don't leave it out, Ack. > and also, I think you should close #1086378, else this doesn't help > with the autoremoval :) > I was thinking about keeping the bug open and downgrade to important so that we keep tracking it. But as I have forwarded it upstream we can monitor the upstream bug directly. I have updated the MR with changelog to close all 3 bugs. PTAL. > -- > Sean Whitton -- Regards, Xiyue Deng signature.asc Description: PGP signature
Re: Anyone interested in python-pgpy?
Hello, On Sat 07 Dec 2024 at 06:56pm -08, Xiyue Deng wrote: > I was thinking about keeping the bug open and downgrade to important so > that we keep tracking it. But as I have forwarded it upstream we can > monitor the upstream bug directly. I think that downgrading it like that would make sense were you the maintainer. But given that we're doing an NMU to deal with RC bugs, just closing is a simpler documentation of your intent. The maintainer might reopen it and downgrade its importance later. Great work figuring out and then documenting these fixes. mailscripts' dependency on python3-pgpy lives on! -- Sean Whitton signature.asc Description: PGP signature
Re: use of waf in pyinstaller (was: blhc)
On December 7, 2024 5:29:39 PM UTC, Soren Stoutner wrote: ... >I have not had any experience with waf before, and so am not aware of DFSG or >malware difficulties that other projects have faced. In the case of >PyInstaller, most of the waf code is contained in: > >https://salsa.debian.org/python-team/packages/pyinstaller/-/tree/debian/ >master/bootloader/waflib?ref_type=heads > >It is written in Python and licensed under the BSD-3-clause. It is used to >compile the C code in: > >https://salsa.debian.org/python-team/packages/pyinstaller/-/tree/debian/ >master/bootloader/src?ref_type=heads > >Which is licensed under the GPL-2+~with-bootloader-exception, which is the >main license of the project. The resulting bootloader (two files) is shipped >in the binary package in /usr/lib/python3/dist-packages/PyInstaller/ >bootloader/Linux-64bit-intel/*. > >None of this looks problematic to me. However, if there are any concerns I >have missed I would be very interested to hear of them before I submit >PyInstaller to the NEW queue. Have a look at the waf entry in the FTP Team reject FAQ: https://ftp-master.debian.org/REJECT-FAQ.html Scott K
Re: use of waf in pyinstaller (was: blhc)
On Saturday, December 7, 2024 11:18:20 AM MST Scott Kitterman wrote: > On December 7, 2024 5:29:39 PM UTC, Soren Stoutner wrote: > ... > > >I have not had any experience with waf before, and so am not aware of DFSG or > >malware difficulties that other projects have faced. In the case of > >PyInstaller, most of the waf code is contained in: > > > >https://salsa.debian.org/python-team/packages/pyinstaller/-/tree/debian/ > >master/bootloader/waflib?ref_type=heads > > > >It is written in Python and licensed under the BSD-3-clause. It is used to > >compile the C code in: > > > >https://salsa.debian.org/python-team/packages/pyinstaller/-/tree/debian/ > >master/bootloader/src?ref_type=heads > > > >Which is licensed under the GPL-2+~with-bootloader-exception, which is the > >main license of the project. The resulting bootloader (two files) is shipped > >in the binary package in /usr/lib/python3/dist-packages/PyInstaller/ > >bootloader/Linux-64bit-intel/*. > > > >None of this looks problematic to me. However, if there are any concerns I > >have missed I would be very interested to hear of them before I submit > >PyInstaller to the NEW queue. > > Have a look at the waf entry in the FTP Team reject FAQ: > > https://ftp-master.debian.org/REJECT-FAQ.html "That's a special case of source code missing. Normally packages using waf as build system contain a Python script with a compressed tarball embedded as a binary blob, where it is not obvious how to get the actual source. As that's not considered to be the preferred form of modification, it fails the DFSG. See #645190 and https://wiki.debian.org/UnpackWaf for details.” As I detailed in the previous email, that does not appear to be the case for PyInstaller. There are no binary blobs that I have found (although I would be interested in knowing if I have missed them). I do understand and agree with such a concern. It just doesn’t appear to be how waf is used by PyInstaller. -- Soren Stoutner so...@debian.org signature.asc Description: This is a digitally signed message part.
Re: use of waf in pyinstaller (was: blhc)
Simon,
Thank you for taking the time to look at this.
On Friday, December 6, 2024 3:27:55 AM MST Simon McVittie wrote:
> On Thu, 05 Dec 2024 at 19:00:50 -0700, Soren Stoutner wrote:
> > I am working on PyInstaller, which is mostly written in Python, but
compiles
> > a bootloader written in c. blhc failes because the [logs] do not contain
> > verbose compile flags.
>
> You'll need to look at the implementation of the build for the C part, and
> then do whatever is most appropriate for that build system.
>
> >From a quick glance at setup.py, it seems to be (a vendored copy of) waf:
> additional_args = os.getenv('PYINSTALLER_BOOTLOADER_WAF_ARGS',
> '').strip().split() cmd = [sys.executable, './waf', 'configure', 'all']
> cmd += additional_args
>
> so hopefully there is something you can add to
> PYINSTALLER_BOOTLOADER_WAF_ARGS that would make waf verbose, analogous
> to `ninja -v` or Autotools `V=1`?
This was a very helpful suggestion. I was able to produce a verbose build by
adding the following to debian/rules:
# Enable the verbose waf build argument so that blhc can analyze the build
flags. waf is the system that builds the bootloader from C code.
export PYINSTALLER_BOOTLOADER_WAF_ARGS = --verbose
> After that, you'll also need to make sure that the intended build
> options are actually used (I don't know whether waf uses CFLAGS, etc. by
> default or has to be given them via waf-specific command-line options).
> Looking at other packages that use a waf build system and implement build
> flags correctly, if any such packages exist, will probably be useful.
The above verbose flag then produces this output in the build logs:
[ 1/21] Compiling src/pyi_utils.c
00:07:52 runner ['/usr/lib/ccache/gcc', '-g', '-O2', '-Werror=implicit-
function-declaration', '-ffile-prefix-map=/builds/python-team/packages/
pyinstaller/debian/output/source_dir=.', '-fstack-protector-strong', '-fstack-
clash-protection', '-Wformat', '-Werror=format-security', '-fcf-protection',
'-Wdate-time', '-D_FORTIFY_SOURCE=2', '-m64', '-O2', '-Wall', '-Werror', '-
Wno-error=unused-variable', '-Wno-error=unused-function', '-Wno-error=unused-
but-set-variable', '-U_FORTIFY_SOURCE', '-Isrc', '-I../../src', '-Iwindows',
'-I../../windows', '-Izlib', '-I../../zlib', '-D_REENTRANT', '-D_BSD_SOURCE',
'-D_DEFAULT_SOURCE', '-D_FORTIFY_SOURCE=2', '-DHAVE_STDBOOL_H=1', '-
DHAVE_UNSETENV=1', '-DHAVE_MKDTEMP=1', '-DHAVE_DIRNAME=1', '-
DHAVE_BASENAME=1', '-DLAUNCH_DEBUG', '-DNDEBUG', '../../src/pyi_utils.c', '-
c', '-o/builds/python-team/packages/pyinstaller/debian/output/source_dir/
bootloader/build/debug/src/pyi_utils.c.1.o', '-Wdate-time', ‘-
D_FORTIFY_SOURCE=2’]
Blhc still reports the above as a NONVERBOSE build because there is a line
break, so the first line is flagged separate from the second line. It turns
out
there is an existing blhc bug report for this, which I have added some
addition information to.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=976175
> We have had problems with waf in the past, both technical and social
> (licensing-related and others), so please be careful to ensure that
> this package meets Debian's quality standards and doesn't contain any
> particularly attractive places to hide malware.
>
> In particular, the recommended way to distribute waf-built code used to
> be to vendor a generated script containing a bzip2-compressed tarball,
> which is not straightforward to review or patch, and the ftp team does
> not consider this to be acceptable in Debian [1]. Is this still the case,
> or is PyInstaller redistributing waf as reviewable/patchable files in
> something more closely resembling their preferred form for modification?
>
> Has the maintainer of this package (possibly you, I don't know this
> package's history) verified that the included copy of waf is something
> that we can trust? From the fact that you didn't already know this
> package is using waf, I would guess perhaps not?
I have not had any experience with waf before, and so am not aware of DFSG or
malware difficulties that other projects have faced. In the case of
PyInstaller, most of the waf code is contained in:
https://salsa.debian.org/python-team/packages/pyinstaller/-/tree/debian/
master/bootloader/waflib?ref_type=heads
It is written in Python and licensed under the BSD-3-clause. It is used to
compile the C code in:
https://salsa.debian.org/python-team/packages/pyinstaller/-/tree/debian/
master/bootloader/src?ref_type=heads
Which is licensed under the GPL-2+~with-bootloader-exception, which is the
main license of the project. The resulting bootloader (two files) is shipped
in the binary package in /usr/lib/python3/dist-packages/PyInstaller/
bootloader/Linux-64bit-intel/*.
None of this looks problematic to me. However, if there are any concerns I
have missed I would be very interested to hear of them before I submit
PyInstaller to the NEW queue.
--
Soren Stoutner
so...@debian.org
signature.as
Re: Anyone interested in python-pgpy?
Hello, On Sat 07 Dec 2024 at 02:27am -08, Xiyue Deng wrote: > Sean Whitton writes: > >> Hello, >> >> Many thanks, and nice documentation of the changes. >> >> If you'd like to send an MR or patch with a d/changelog entry, I can >> upload the NMU credited to you. >> > > Sounds good. I have the MR for updating d/changelog at [1]. I have a > separate commit to finalize in case there are any comments to address. > Please let me know if I should leave out the finalization instead. > Thanks! No, don't leave it out, and also, I think you should close #1086378, else this doesn't help with the autoremoval :) -- Sean Whitton signature.asc Description: PGP signature
Re: Upload request: psrecord (NEW)
Hi Alexandru,
On 2024-12-06 17:13:18, Alexandru Mihail wrote:
Pinging about (upload) my last mail, I cleaned up upstream mess on
psrecord now and I think it's ready for upload. Would really appreciate
your scrutiny one last time.
I am mostly happy now. There are two issues left:
1. The generated man page is not cleaned up. As a result the package
clean-up validation (see [0]) fails:
--
diff /tmp/file-list.pre-build /tmp/file-list.post-build
---
17c17
< /<>/debian directory 220
---
> /<>/debian directory 240
21a22
> /<>/debian/psrecord.1 regular file 1427
fbcd91b4cb61d6616892a323e65daee05a54131e6177ae5b81da9ee4276722a6
--
Adding a line
rm -f debian/psrecord.1
to the override_dh_auto_clean target in debian/rules should fix this.
2. The timestamp of the changelog entry is older than the most recent
commit (excluding commits that modify the changelog file).
Bonus item (optional):
In my opinion the legibility of debian/rules files is increased by
adding empty lines between the various targets.
The same also applies to the license text in debian/copyright (cf. lines
3 and 6 of the upstream LICENSE file [1]). Please note that "empty"
lines in the "License" fields of debian/copyright files are denoted by a
dot (".") in the second column.
Best regards
Peter
[0] https://wiki.debian.org/sbuild#Validate_package_cleanup
[1]
https://github.com/astrofrog/psrecord/blob/cda423ed3fa00fadad66cd7a28ed342748d9f88e/LICENSE
Re: Anyone interested in python-pgpy?
Sean Whitton writes: > Hello, > > Many thanks, and nice documentation of the changes. > > If you'd like to send an MR or patch with a d/changelog entry, I can > upload the NMU credited to you. > Sounds good. I have the MR for updating d/changelog at [1]. I have a separate commit to finalize in case there are any comments to address. Please let me know if I should leave out the finalization instead. Thanks! > -- > Sean Whitton [1] https://salsa.debian.org/debian/pgpy/-/merge_requests/3 -- Regards, Xiyue Deng signature.asc Description: PGP signature
Re: Anyone interested in python-pgpy?
Hello, Many thanks, and nice documentation of the changes. If you'd like to send an MR or patch with a d/changelog entry, I can upload the NMU credited to you. -- Sean Whitton signature.asc Description: PGP signature
