Bug#919637: RFS: elinks/0.13~20190114-1 [ITA]
Package: sponsorship-requests Severity: normal Hello, I am adopting elinks. I have worked on the fork that Moritz has mentioned: https://github.com/rkd77/felinks I have emailed previous upstream maintainers,asking them if they are still maintaining elinks. Two emails bounced back, and I still got no reply from the others. Anyways, this upload is targetting experimental, as I have enabled several features like Bittorrent and Javascript. This upload fixes the following bugs #740981 (normal): elinks: doesn't check if hostname matches certificate's CN/SAN (CWE-297) #757631 (normal): elinks: HTML5 source element display missing #797931 (normal): elinks: Does not support SSL rehandshakes #797934 (wishlist): elinks: Support for SSL authentication using client certs #797968 (wishlist): elinks: Please add support for TLS SNI #856852 (normal): cert_verify is disabled by default #866015 (important): elinks: SSL error with some websites #879539 (minor): elinks: contains code related to gnutls pgp supprt #891575 (important): elinks: CVE-2012-6709 #917406 (normal): ITA: elinks -- advanced text-mode WWW browser Last changelog entry is: elinks (0.13~20190114-1) experimental; urgency=medium * New upstream release (Closes: #891575, #797931, #797934, #757631, #866015, #797968, #740981, #865852) * Add git-buildpackage conf file * Refreshed patches & removed patches that were includes upstream. Removed patches: 08-drop-deprecated-gnutls-functions.diff (Closes: #879539) 08_524696_fix_imdb_urls.diff 09-Switch-to-use-lua-5.1.diff * Add libgcrypt20-dev to build deps * Re-added 14_debug_disable_Werror.diff to enable development versions debug support * Added 16_POST_BUFFER_SIZE.diff patch which to enable uploading large files over https:// connections. * Add ascii-replacement-utf8-console.diff patch to print ASCII replacement for characters not found in current codepage in utf8 mode * Enable LZMA support * Enable BitTorrent * Enable NNTP Support * Enable Unicode combining characters support * Enable EX mode support * Enable SpiderMonkey support * Enable terminfo support * Build documentation * Build with libev * Bumped to compat level 12. No need to have dh-autoreconf, autotools-dev from build deps Also no need to explicitly call the respective sequences in rules * Remove old upstream gpg key. * Remove whitespaces * Renamed elinks.config to elinks.conf, old name confused build scrips * debian/rules: Override dh_installexamples to exclude .gitignore * Add typos.diff patch to fix spelling mistakes * debian/control: + Replace Conflicts with Breaks+Replaces + Update standards version to 4.3.0 + New maintainer (Closes: #917406) + Add Vcs-* fields * Add upstream metadata * Switch to DEP-5 copyright format * Disable pristine-tar, since we are getting the release from upstream git There is one lintian warning: W: elinks-data: manpage-has-errors-from-man usr/share/man/man5/elinks.conf.5.gz 1166: warning [p 14, 7.0i]: can't break line The package is on: g...@salsa.debian.org:aelmahmoudy-guest/elinks.git , felinks branch To access further information about this package, please visit the following URL: https://mentors.debian.net/package/elinks Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/e/elinks/elinks_0.13~20190114-1.dsc -- أحمد المحمودي (Ahmed El-Mahmoudy) Digital design engineer GPG KeyIDs: 4096R/A7EF5671 2048R/EDDDA1B7 GPG Fingerprints: 6E2E E4BB 72E2 F417 D066 6ABF 7B30 B496 A7EF 5761 8206 A196 2084 7E6D 0DF8 B176 BC19 6A94 EDDD A1B7 signature.asc Description: PGP signature
Bug#919614: RFS: note/1.3.26-2 [ITA]
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "note" * Package name: note Version : 1.3.26-2 Upstream Author : Thomas von Dein * URL : http://www.daemon.de/NOTE * License : Gnu Public License(GPL) Section : utils It builds those binary packages: note - small program managing notes from commandline To access further information about this package, please visit the following URL: https://mentors.debian.net/package/note Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/n/note/note_1.3.26-2.dsc More information about note can be obtained from http://www.daemon.de/NOTE Changes since the last upload: * New Maintainer (Closes: 900663). - Add me to Maintainer Field on d/control. - Update Vcs-* field to my own repo. - Add me to Copyright field for debian/* files. Regards, Emmanuel Arias -- Arias Emmanuel http://eamanu.com Github/Gitlab; @eamanu Debian: @eamanu-guest
Bug#919590: RFS: openliberty/18.0.0.4 [ITP]
Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my package "openliberty" * Package name: openliberty Version : 18.0.0.4 Upstream Author : https://groups.io/g/openliberty * URL : https://openliberty.io/downloads/ * License : EPL-2.0 Section : java It builds those binary packages: openliberty - Open Liberty provides developers with proven Java EE 8 technology To access further information about this package, please visit the following URL: https://mentors.debian.net/package/openliberty Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/o/openliberty/openliberty_18.0.0.4.dsc More information about openliberty can be obtained from https://openliberty.io Changes since the last upload: openliberty (18.0.0.4) unstable; urgency=medium * Initial release * This is my first debian package for Open Liberty -- Michael Zhang Wed, 10 Oct 2018 12:56:59 -0700 Regards, Michael Zhang
Re: lintian warnings - help requested
On Thu, 17 Jan 2019 at 21:53, Andrey Rahmatullin wrote: > > On Thu, Jan 17, 2019 at 09:31:12PM +1100, Andrew Worsley wrote: > > > > I don't have a sponsor (suggestions of where to look welcomed). > > > https://mentors.debian.net/intro-maintainers > > > > I got no bites previously - perhaps I have to make a stronger case to > > more users. > Sorry? This is my 2nd attempt to package - I previously uploaded it - built against stretch but it recently expired with no sponsors... So this is my 2nd go - I figured I would move on to buster as it's nearing completion. > > > > 2. The source-is-missing .html/.js files with very long lines - > > > > Should I override them? Or try to wrap the lines? > > > If they are sources in the preferred form for modification, why do they > > > have long and not human-editable lines? If they are not actually sources > > > you need to provide sources and build the resulting files from them. > > > > > > > Looks like unit test data (base64 encoded blobs). > > Might try to wrap the lines - or strip them. > You shouldn't wrap the lines just to appease lintian. You should fix the > initial problem or override lintian if lintian is wrong. I don't see any alternative - these files were in the original package - not generated files or anything.
Re: lintian warnings - help requested
On Thu, Jan 17, 2019 at 09:31:12PM +1100, Andrew Worsley wrote: > > > I don't have a sponsor (suggestions of where to look welcomed). > > https://mentors.debian.net/intro-maintainers > > I got no bites previously - perhaps I have to make a stronger case to > more users. Sorry? > > > 2. The source-is-missing .html/.js files with very long lines - > > > Should I override them? Or try to wrap the lines? > > If they are sources in the preferred form for modification, why do they > > have long and not human-editable lines? If they are not actually sources > > you need to provide sources and build the resulting files from them. > > > > Looks like unit test data (base64 encoded blobs). > Might try to wrap the lines - or strip them. You shouldn't wrap the lines just to appease lintian. You should fix the initial problem or override lintian if lintian is wrong. > > > Finally is there any way of running the lintian check with out > > > building the whole package ? > > Well, how can you check a package that doesn't exist? > > You can run lintian against the source package to check the source package > > problems though. > > Ok I guess that is >dpkg-buildpackage -S > which is must faster but I think I need to increment the delta in the > change log to make it generate an updated debian source package? I'm sure it always overwrites. -- WBR, wRAR signature.asc Description: PGP signature
Re: lintian warnings - help requested
On Thu, 17 Jan 2019 at 20:22, Andrey Rahmatullin wrote: > > On Thu, Jan 17, 2019 at 08:05:42PM +1100, Andrew Worsley wrote: > > I don't have a sponsor (suggestions of where to look welcomed). > https://mentors.debian.net/intro-maintainers I got no bites previously - perhaps I have to make a stronger case to more users. > > I assume the Errors are show stoppers... > > > > 1. Should I strip out the .exe files from the github repository and > > ignore any worries about people who might try to build it on Windows? > It doesn't matter for Debian. Only the source package contents matter. Ok - I'll strip them out but keep them in a another "original branch" > > 2. The source-is-missing .html/.js files with very long lines - > > Should I override them? Or try to wrap the lines? > If they are sources in the preferred form for modification, why do they > have long and not human-editable lines? If they are not actually sources > you need to provide sources and build the resulting files from them. > Looks like unit test data (base64 encoded blobs). Might try to wrap the lines - or strip them. > > 3. The embedded-library issues - I assume there is not much choice > > but to strip the code out and try and link against the relevant > > packaged library? > Yes, of course. > Sigh. Ok good learning experience I guess. > > Finally is there any way of running the lintian check with out > > building the whole package ? > Well, how can you check a package that doesn't exist? > You can run lintian against the source package to check the source package > problems though. Ok I guess that is dpkg-buildpackage -S which is must faster but I think I need to increment the delta in the change log to make it generate an updated debian source package? > > > It's 30mb source code and dpkg-buildpackage takes a while. > ccache > Ok - will look into that - sounds like it is definitely worth learning how to leverage it According to http://frungy.org/debian/ccache-building-packages: debuild --preserve-envvar=CCACHE_DIR \ --prepend-path=/usr/lib/ccache \ -us -uc * Or https://debian-administration.org/article/129/Speeding_up_recompilation_with_ccache apt-get install ccache export PATH=/usr/lib/ccache:$PATH > Also, is this a fork of some old mozilla code? I'm not sure we want some > old mozilla code in the archive. It's a XUL application - which as far as I can tell looks a lot like mozilla code. I don't think there is an open source alternative that is nearly functionally equivalent. The original system was taken proprietary https://www.celtx.com and no longer made available. As many writers/community groups have little money this software provides the only free alternative for these groups. At least until something better arrives. Thanks again. Very helpful to to get some tips on these things. Andrew
Re: lintian warnings - help requested
On Thu, Jan 17, 2019 at 08:05:42PM +1100, Andrew Worsley wrote: > I don't have a sponsor (suggestions of where to look welcomed). https://mentors.debian.net/intro-maintainers > I assume the Errors are show stoppers... > > 1. Should I strip out the .exe files from the github repository and > ignore any worries about people who might try to build it on Windows? It doesn't matter for Debian. Only the source package contents matter. > 2. The source-is-missing .html/.js files with very long lines - > Should I override them? Or try to wrap the lines? If they are sources in the preferred form for modification, why do they have long and not human-editable lines? If they are not actually sources you need to provide sources and build the resulting files from them. > 3. The embedded-library issues - I assume there is not much choice > but to strip the code out and try and link against the relevant > packaged library? Yes, of course. > Finally is there any way of running the lintian check with out > building the whole package ? Well, how can you check a package that doesn't exist? You can run lintian against the source package to check the source package problems though. > It's 30mb source code and dpkg-buildpackage takes a while. ccache Also, is this a fork of some old mozilla code? I'm not sure we want some old mozilla code in the archive. -- WBR, wRAR signature.asc Description: PGP signature
lintian warnings - help requested
I am compiling a script writing package (celtx) which compiles on buster with lintian errors and would appreciate some suggestions about how to fix them. In particular when should I add overrides or fix the upstream source (which may prevent it from building on non-debian machines?) It's an old piece of software but still used by some (at least one) person as a open source script writing software package (apparently quite good). The details are: Upstream code is my github repository: https://github.com/amworsley/open-celtx I don't have a sponsor (suggestions of where to look welcomed). I assume the Errors are show stoppers... 1. Should I strip out the .exe files from the github repository and ignore any worries about people who might try to build it on Windows? 2. The source-is-missing .html/.js files with very long lines - Should I override them? Or try to wrap the lines? 3. The embedded-library issues - I assume there is not much choice but to strip the code out and try and link against the relevant packaged library? Seems likely to be significant work. Finally is there any way of running the lintian check with out building the whole package ? It's 30mb source code and dpkg-buildpackage takes a while. This is probably basic stuff that many DDs just know off the top of their head but unfortunately I don't know any to answer my questions. Thanks in advance Andrew The errors are: W: open-celtx source: source-contains-prebuilt-windows-binary mozilla/config/bin2rc.exe W: open-celtx source: source-contains-prebuilt-windows-binary mozilla/config/makedep.exe W: open-celtx source: source-contains-prebuilt-windows-binary mozilla/config/mangle.exe W: open-celtx source: source-contains-prebuilt-windows-binary ... use --no-tag-display-limit to see all (or pipe to a file/program) E: open-celtx source: source-is-missing mozilla/docshell/test/navigation/test_bug430723.html line length is 438 characters (>256) E: open-celtx source: source-is-missing mozilla/js/src/t/string-tagcloud.js line length is 25744 characters (>512) E: open-celtx source: source-is-missing mozilla/js/src/t/string-unpack-code.js line length is 32318 characters (>512) E: open-celtx source: source-is-missing ... use --no-tag-display-limit to see all (or pipe to a file/program) E: open-celtx source: license-problem-convert-utf-code mozilla/toolkit/crashreporter/google-breakpad/src/common/convert_UTF.c W: open-celtx source: patch-file-present-but-not-mentioned-in-series more-branding-fixes W: open-celtx source: debian-rules-should-not-use-or-modify-user-only-variable line 11 W: open-celtx source: debian-rules-should-not-use-or-modify-user-only-variable line 12 E: open-celtx: embedded-library usr/lib/celtx/celtx-bin: lcms E: open-celtx: embedded-library usr/lib/celtx/celtx-bin: libjpeg E: open-celtx: embedded-library usr/lib/celtx/celtx-bin: zlib E: open-celtx: embedded-library ... use --no-tag-display-limit to see all (or pipe to a file/program) W: open-celtx: wrong-bug-number-in-closes l53:# W: open-celtx: extended-description-line-too-long W: open-celtx: extended-description-line-too-long W: open-celtx: extended-description-line-too-long W: open-celtx: unknown-section Graphics W: open-celtx: jar-not-in-usr-share usr/lib/celtx/chrome/calendar-en-US.jar W: open-celtx: jar-not-in-usr-share usr/lib/celtx/chrome/calendar.jar W: open-celtx: jar-not-in-usr-share usr/lib/celtx/chrome/celtx.jar W: open-celtx: jar-not-in-usr-share ... use --no-tag-display-limit to see all (or pipe to a file/program) W: open-celtx: menu-command-not-in-package usr/share/menu/open-celtx:2 usr/bin/open-celtx W: open-celtx: menu-item-needs-tag-has-unknown-value x11|text|vc|wm usr/share/menu/open-celtx:2 W: open-celtx: menu-item-creates-new-section Applications/see-menu-manual usr/share/menu/open-celtx:2 W: open-celtx: executable-not-elf-or-script usr/lib/celtx/removed-files W: open-celtx: executable-not-elf-or-script usr/lib/celtx/defaults/profile/CeltxSamples/5_ComicSampleProject.celtx W: open-celtx: executable-not-elf-or-script usr/lib/celtx/defaults/profile/CeltxTemplates/6_ComicBook.celtx W: open-celtx: executable-not-elf-or-script ... use --no-tag-display-limit to see all (or pipe to a file/program) N: 0 tags overridden; 1 unused override
Re: Meaning of "Checking build-dependency (indep) on amd64" excuse
Hi Feri, Please CC me on reply. >> I think I understand the rest, although I don't know whether the >> autopkgtest regression blocks migration indefinitely. That would be >> unfortunate, because unstable pcs needs unstable pacemaker, so they >> deadlock... > > I think you will need to ask the release team to hint them in > together. Yes, they will block unless overridden by the release team, or better, when you change your package relations such that the migration software figures out that they need to be tested together. (The release team and I can do the latter manually, but that is not really sustainable.) With the current code your options are: - *versioned* depends on one of the binary packages from the source you want from unstable in any of the binary packages that is going to be taken from unstable already - *versioned* breaks or conflicts on the binary packages from the source you want from unstable in any of the binary packages that is going to be taken from unstable - *versioned* test dependency in the package that is used for autopkgtest (only helps if the version that is tested is already taken from unstable). The version of the test dependency will NOT be added to the triggers, but if the version of the autopktest is going to be taken from unstable already due to other considerations, with the current settings of ci.d.n and autopkgtest the required version will be installed. Mind you, if the migration software asks for a test with multiple packages from unstable (visible in the triggers string) a PASS will be used for all those packages, so you only need to "fix" this in one package. Paul signature.asc Description: OpenPGP digital signature
