Bug#840515: RFS: open-ath9k-htc-firmware/1.4.0-25-gf6af791-1 ITP #751339
Am 13.10.2016 um 05:55 schrieb Paul Wise: > On Wed, Oct 12, 2016 at 7:38 PM, Paul Fertser wrote: > >> Cc: Oleksij Rempel > > Please use the X-Debbugs-CC pseudo-header when submitting bugs instead > of CC, so that the recipients get the bug number too. Put it just > after Severity in the mail body so those CCed can see it: > > https://www.debian.org/Bugs/Reporting#xcc > >> I am looking for a sponsor for my package "open-ath9k-htc-firmware" > > Correct me if I'm wrong but IIRC either yourself or Oleksij have > commit/release access upstream? correct. > The comments for the overrides for lintian tag source-is-missing > should indicate which file is the source for each prebuilt file. I > would have one comment per instance of the tag. Just one comment > saying they are removed at build time is enough for all of the > overrides for lintian tag source-contains-prebuilt-binary. Personally, > I would suggest removing all of these files from the upstream git > repository and always building them from source. If you need to keep > them, put them in tarballs in the github releases. I can answer this part, especially because most of comments are related to sboot/ folder. sboot contains ROM code flashed to the chip or eeprom. Not all ROM parts seems to be open (fix me if i'm wrong), but at least contain some binary. If some person will decide to RE closed parts, it will be easier to know what exactly should be RE instead of work on complete ROM. No one will ever touch/patch sboot. At least i will not allow it. The actual firmware is located in RAM and to reduce memory usage, it is using ROM functions. To understand what is used and to be able to fix any thing in the firmware you need to read sboot. The sboot should reflect state of the code with all this bugs and problems. Even if this is wrong FSF address. For most paranoid persons we remove sboot before build is started. > Personally, I would recommend the generated files docs/*.png be > removed from the upstream git repo and rendered at build time from > their source SVG files if they are needed. ok, i'll remove pngs. > I think you should also remove the prebuilt files before > dh_auto_configure so that they can never get used by a build, even a > manual one where `debian/rules clean` is not run. > > What is the reason for removing the docs/ and sboot/ directories in > override_dh_clean? AFAICS both of these contain source files. IMO you > should just remove the generated files. > > The cmake part of the build process does not print compiler > invocation. Debian requires full compiler flags/output in build logs. > For cmake usually debhelper automatically passes > -DCMAKE_VERBOSE_MAKEFILE=ON but it doesn't seem to be working here? > > The debian/watch file needs adjusting for the new source package name: > s/firmware-ath9k-htc/open-ath9k-htc-firmware/ > > Personally I would leave "debian uupdate" out of the watch file > because it can be annoying for people who just want to download. > > I would use a debian/clean file instead of override_dh_clean. > > Please get the FSF address corrected in the upstream copyright info. > > debian/cross-toolchain.mk needs copyright/license info filled in, > preferably in both the header of it and in debian/control. > > The Uploaders field is empty. I would have expected to your name there > if you intend to co-maintain it with Oleksij. > > I would recommend running this command (from the devscripts package) > so that future diffs of the Debian packaging are easier to read: > > wrap-and-sort --short-indent --wrap-always --sort-binary-packages > --trailing-comma > > The Vcs-* fields should point at the repository containing the Debian > packaging, not upstream: > > https://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-VCS-fields > > The Conflicts/Suggests fields are empty, you can remove them from > debian/control. > > For merged bugs, you only need to close one of them and the rest will > be closed too. > > What is the reason for renaming the upstream firmware files? Does the > Linux kernel detect the new names? upstream file names have old name schema without version numbers. Since we are not able to guarantee 100% backwards compatibility and testing coverage for all available kernel version we need to have different fw binaries for different version. For example linux-firmware repo contains both 1.3 and 1.4 binaries. The same is about debian firmware-atheros packet, it contains: /lib/firmware/ath9k_htc/htc_7010-1.4.0.fw /lib/firmware/ath9k_htc/htc_9271-1.4.0.fw /lib/firmware/htc_7010.fw /lib/firmware/htc_9271.fw Only way to avoid conflict between packages and be able to provide FW version different from actual realise, for example with security fixes is to use /lib/firmware/ath9k_htc/htc_9271-1.dev.0.fw name. To tell the kernel that this should be used, we need to provide ath9k_htc.conf At same time Adrian Chadd is promising to provide BSD driver for this HW. Which FW names he will use
Bug#840598: RFS: poppassd/1.8.7-1 [QA]
Package: sponsorship-requests Severity: normal Dear mentors, Following up on the NMU (#839859) uploaded last week thanks to Adam Borowski, I am looking for a sponsor for a QA upload of poppassd. git clone https://anonscm.debian.org/git/collab-maint/poppassd.git cd poppassd && pristine-tar checkout ../poppassd_1.8.7.orig.tar.gz For verification, these are the current branch heads: git show-ref --heads 10415d0de0a5daa3bb221afdf39f777ccc7a5734 refs/heads/master db27d6addd476baf420d49f362b79b373462063e refs/heads/pristine-tar 79da3cf634ebe761d494fcbbcf36a4da71379383 refs/heads/upstream Changes since the last upload: poppassd (1.8.7-1) unstable; urgency=medium * New upstream release * Switch source format to 3.0 (quilt) * Use dh with autoreconf in debian/rules (Closes: #817626) * Build with hardening flags * Add machine-readable debian/copyright * Update Homepage field * Add Vcs-Git and Vcs-Browser fields * Update debian/watch * Run wrap-and-sort * Update Standards-Version to 3.9.8 * Add debian/gbp.conf for pristine-tar * Add myself to Uploaders after consulting with MIA team (Closes: #836008) -- Peter Colberg Thu, 13 Oct 2016 00:04:08 -0400 Please see #839859 and #836008 for background information. If you have any further questions, please contact Ricardo Mones from the MIA team. If you decide to sponsor this package, please upload the source only so that buildd logs are available for all archs. I will push a release tag to the git repository after the package has been uploaded. I suggest uploading this version to DELAYED/7 to allow the NMU to migrate to testing and give the maintainer another week to respond. Regards, Peter
Bug#840515: RFS: open-ath9k-htc-firmware/1.4.0-25-gf6af791-1 ITP #751339
On Wed, Oct 12, 2016 at 7:38 PM, Paul Fertser wrote: > Cc: Oleksij Rempel Please use the X-Debbugs-CC pseudo-header when submitting bugs instead of CC, so that the recipients get the bug number too. Put it just after Severity in the mail body so those CCed can see it: https://www.debian.org/Bugs/Reporting#xcc > I am looking for a sponsor for my package "open-ath9k-htc-firmware" Correct me if I'm wrong but IIRC either yourself or Oleksij have commit/release access upstream? The comments for the overrides for lintian tag source-is-missing should indicate which file is the source for each prebuilt file. I would have one comment per instance of the tag. Just one comment saying they are removed at build time is enough for all of the overrides for lintian tag source-contains-prebuilt-binary. Personally, I would suggest removing all of these files from the upstream git repository and always building them from source. If you need to keep them, put them in tarballs in the github releases. Personally, I would recommend the generated files docs/*.png be removed from the upstream git repo and rendered at build time from their source SVG files if they are needed. I think you should also remove the prebuilt files before dh_auto_configure so that they can never get used by a build, even a manual one where `debian/rules clean` is not run. What is the reason for removing the docs/ and sboot/ directories in override_dh_clean? AFAICS both of these contain source files. IMO you should just remove the generated files. The cmake part of the build process does not print compiler invocation. Debian requires full compiler flags/output in build logs. For cmake usually debhelper automatically passes -DCMAKE_VERBOSE_MAKEFILE=ON but it doesn't seem to be working here? The debian/watch file needs adjusting for the new source package name: s/firmware-ath9k-htc/open-ath9k-htc-firmware/ Personally I would leave "debian uupdate" out of the watch file because it can be annoying for people who just want to download. I would use a debian/clean file instead of override_dh_clean. Please get the FSF address corrected in the upstream copyright info. debian/cross-toolchain.mk needs copyright/license info filled in, preferably in both the header of it and in debian/control. The Uploaders field is empty. I would have expected to your name there if you intend to co-maintain it with Oleksij. I would recommend running this command (from the devscripts package) so that future diffs of the Debian packaging are easier to read: wrap-and-sort --short-indent --wrap-always --sort-binary-packages --trailing-comma The Vcs-* fields should point at the repository containing the Debian packaging, not upstream: https://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-VCS-fields The Conflicts/Suggests fields are empty, you can remove them from debian/control. For merged bugs, you only need to close one of them and the rest will be closed too. What is the reason for renaming the upstream firmware files? Does the Linux kernel detect the new names? What is the reason for debian/ath9k_htc.conf? Why is it Debian-specific instead of being committed upstream? I'd recommend either passing --parallel at the end of the args to dh, or upgrading to debian/compat 10, which uses that by default. Please add some upstream metadata: https://wiki.debian.org/UpstreamMetadata I'd suggest signing all tarballs, tags and commits with OpenPGP and having uscan verify the tarball sigs: https://wiki.debian.org/Creating%20signed%20GitHub%20releases https://mikegerwitz.com/papers/git-horror-story https://wiki.debian.org/debian/watch#Cryptographic_signature_verification https://help.riseup.net/en/security/message-security/openpgp/best-practices Automatic checks: build: Various gcc and other warnings. lintian: P: open-ath9k-htc-firmware source: debian-watch-may-check-gpg-signature P: firmware-ath9k-htc: no-upstream-changelog I: firmware-ath9k-htc: extended-description-is-probably-too-short P: firmware-ath9k-htc-dbgsym: no-upstream-changelog I: firmware-ath9k-htc-dbgsym: extended-description-is-probably-too-short check-all-the-things: $ env PERL5OPT=-m-lib=. cme check dpkg Warning in 'copyright Format' value 'http://www.debian.org/doc/packaging-manuals/copyright-format/1.0/': Format uses insecure http protocol instead of https you can try 'cme fix dpkg' to fix the warnings shown above $ codespell --quiet-level=3 $ cppcheck -j1 --quiet -f . [sboot/magpie_1_1/sboot/athos/src/xtos/xtos-internal.h:142]: (error) syntax error [sboot/utility/adjust_dep/adj_dep.c:63]: (error) Buffer overrun possible for long command line arguments. [sboot/utility/adjust_time/adj_time.c:57]: (error) Buffer overrun possible for long command line arguments. [sboot/utility/adjust_time/adj_time.c:58]: (error) Buffer overrun possible for long command line arguments. [sboot/utility/bin2hex/bin2hex.c:197]: (error) Buffer overrun possible for long command line arguments. [sboot/uti
Re: Finding the correct alignment for all architectures
* Christian Seiler , 2016-10-13, 00:20: On 10/12/2016 11:51 PM, Thomas Weber wrote: I am maintaining lcms2. In #749975, I received a patch to ensure correct alignment for doubles von MIPS. I have forwarded the patch upstream[1], but in the latest release, upstream has chosen a different way. It is now possible to configure the alignment via a preprocessor variable CMS_PTR_ALIGNMENT[2]: [...] I would like to drop the Debian-specific patch. But what value for CMS_PTR_ALIGNMENT would be good/sufficient on all arches? Use _Alignof(type), that will always be correct. :-) For example: #define POINTER_ALIGNMENT_Alignof(void *) #define DOUBLE_ALIGNMENT _Alignof(double) If you are not delighted with leading underscores, you can #include and then do s/_Alignof/alignof/. Technically, this was introduced in C11/C++11, so if you need to support really old compilers, this may be problematic, but gcc/clang have supported that for a while. (A quick test tells me that gcc and clang from Jessie already support it.) gcc in wheezy supports it too. Alternatively, you may want to use the (gcc-specific) __BIGGEST_ALIGNMENT__ macro, but that kinda wasteful. For example, on i386 it's 16, even though alignof(t) is <= 4 for most t you can think of. -- Jakub Wilk
Re: Finding the correct alignment for all architectures
Hi, On 10/12/2016 11:51 PM, Thomas Weber wrote: > I am maintaining lcms2. In #749975, I received a patch to ensure correct > alignment for doubles von MIPS. I have forwarded the patch upstream[1], but > in the latest release, upstream has chosen a different way. It is now > possible to configure the alignment via a preprocessor variable > CMS_PTR_ALIGNMENT[2]: > // Alignment to memory pointer > > // (Ultra)SPARC with gcc requires ptr alignment of 8 bytes > // even though sizeof(void *) is only four: for greatest flexibility > // allow the build to specify ptr alignment. > #ifndef CMS_PTR_ALIGNMENT > # define CMS_PTR_ALIGNMENT sizeof(void *) > #endif > > #define _cmsALIGNMEM(x) (((x)+(CMS_PTR_ALIGNMENT - 1)) & ~(CMS_PTR_ALIGNMENT > - 1)) > > I would like to drop the Debian-specific patch. But what value for > CMS_PTR_ALIGNMENT would be good/sufficient on all arches? Use _Alignof(type), that will always be correct. :-) For example: #define POINTER_ALIGNMENT_Alignof(void *) #define DOUBLE_ALIGNMENT _Alignof(double) Technically, this was introduced in C11/C++11, so if you need to support really old compilers, this may be problematic, but gcc/clang have supported that for a while. (A quick test tells me that gcc and clang from Jessie already support it.) Regards, Christian
Finding the correct alignment for all architectures
Hi, I am maintaining lcms2. In #749975, I received a patch to ensure correct alignment for doubles von MIPS. I have forwarded the patch upstream[1], but in the latest release, upstream has chosen a different way. It is now possible to configure the alignment via a preprocessor variable CMS_PTR_ALIGNMENT[2]: // Alignment to memory pointer // (Ultra)SPARC with gcc requires ptr alignment of 8 bytes // even though sizeof(void *) is only four: for greatest flexibility // allow the build to specify ptr alignment. #ifndef CMS_PTR_ALIGNMENT # define CMS_PTR_ALIGNMENT sizeof(void *) #endif #define _cmsALIGNMEM(x) (((x)+(CMS_PTR_ALIGNMENT - 1)) & ~(CMS_PTR_ALIGNMENT - 1)) I would like to drop the Debian-specific patch. But what value for CMS_PTR_ALIGNMENT would be good/sufficient on all arches? [1] https://github.com/mm2/Little-CMS/issues/32 [2] https://github.com/mm2/Little-CMS/blob/master/src/lcms2_internal.h Thanks Thomas
Re: Bug#837798: RFS: libcgicc/3.2.16-0.1 NMU -- C++ class library for writing CGI applications
On 2016-10-11 22:22, Gianfranco Costamagna wrote: I see you forgot to probably run dh_clean (I see debian/autoreconf.before and debian/autoreconf.after files) D'oh. They were leftovers from a previous build and are gone now. and I still see a libcgicc3-dev package (instead of libcgicc-dev) Yes, that was my mistake; I misunderstood your suggestion and made libcgicc-dev a virtual package. The last update on mentors now consists of libcgicc3, libcgicc-dev and libcgicc-doc. Thanks, Thomas
Bug#840450: marked as done (RFS: peg-solitaire/2.1-1 (package already in Debian))
Your message dated Wed, 12 Oct 2016 14:02:44 + (UTC) with message-id <1275833396.8164495.1476280964...@mail.yahoo.com> and subject line Re: Bug#840450: RFS: peg-solitaire/2.1-1 (package already in Debian) has caused the Debian Bug report #840450, regarding RFS: peg-solitaire/2.1-1 (package already in Debian) to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 840450: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=840450 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "peg-solitaire" * Package name: peg-solitaire Version : 2.1-1 Upstream Author : I. De Marchi * URL : http://sourceforge.net/projects/peg-solitaire/ * License : GPL-3 Section : games It builds those binary packages: peg-solitaire - Board game for one player with pegs To access further information about this package, please visit the following URL: https://mentors.debian.net/package/peg-solitaire Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/p/peg-solitaire/peg-solitaire_2.1-1.dsc Changes since the last upload: * New upstream release. * Migrated to Qt 5: + Changes build-depends consecuentely in debian/control. * Add cmake build system: + Changes build-depends to cmake in debian/control. * Update to Standards-Version 3.9.8 (not special changes required). * Update year in debian/copyright file. * Remove debian/peg-solitaire.menu file by the tech-ctte decision on #741573. * Add upstream signing key to debian/upstream/signing-key.asc. + Add pgpsigurlmangle option in debian/watch file. * Add Vcs-Browser and Vcs-Git fields in debian/control file. * Removed Uploaders field from debian/control file. The package is lintian clean! Regards, Innocent De Marchi --- End Message --- --- Begin Message --- Hi, >I am looking for a sponsor for my package "peg-solitaire" done :) G.--- End Message ---
Bug#836903: RFS: qevercloud/3.0.2+ds-1 [ITP] -- Unofficial Evernote Cloud API library for Qt
Hello Boyuan, On Wed, Oct 12, 2016 at 11:03:43AM +0800, Boyuan Yang wrote: > 2016-10-12 10:43 GMT+08:00 Sean Whitton : > > Have you read /usr/share/doc/doxygen/README.jquery? > > > > I think you shouldn't be symlinking jquery. > > Wow, I did not read it before since I trusted lintian :p That's usually reasonable! > Looks like it is kind of disagreement between the packager / uploader > of doxygen and debian policy. Debian Policy often lags behind best practices. It's not necessarily a disagreement, just that the process to update policy hasn't concluded. > I found bug #736360 and dh_doxygen really interesting, but still kind > of confused. dh_doxygen did not mention this embedding problem in its > manpage, and those Debian bug reports did not give a final solution > either. So what should I do? Just override the lintian warning? Sorry, dh_doxygen is different from the jquery issue. I suggest: 1) override the jquery warning, with a comment pointing to README.jquery (there is a special format for lintian override comments) 2) ensure that dh_doxygen is run after you build the documentation. It does various things like symlink template files. -- Sean Whitton signature.asc Description: PGP signature
Bug#840502: marked as done (RFS: shadowsocks-libev/2.4.8+ds-1~bpo8+1 -- lightweight and secure socks5 proxy)
Your message dated Wed, 12 Oct 2016 13:30:54 + (UTC) with message-id <876169787.8127234.1476279054...@mail.yahoo.com> and subject line Re: Bug#840502: RFS: shadowsocks-libev/2.4.8+ds-1~bpo8+1 -- lightweight and secure socks5 proxy has caused the Debian Bug report #840502, regarding RFS: shadowsocks-libev/2.4.8+ds-1~bpo8+1 -- lightweight and secure socks5 proxy to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 840502: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=840502 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- package: sponsorship-requests severity: normal X-Debbugs-Cc: rogershim...@gmail.com, max.c...@gmail.com, 073p...@gmail.com Dear mentors, I am looking for a sponsor for my package "shadowsocks-libev" for jessie-backports. * Package name: shadowsocks-libev Version : 2.4.8+ds-1~bpo8+1 Upstream Author : Max Lv * URL : https://www.shadowsocks.org * License : GPL-3+ Section : net It builds those binary packages: libshadowsocks-dev - lightweight and secure socks5 proxy (development files) libshadowsocks1 - lightweight and secure socks5 proxy (shared library) shadowsocks-libev - lightweight and secure socks5 proxy To access further information about this package, please visit the following URL: https://mentors.debian.net/package/shadowsocks-libev Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/s/shadowsocks-libev/shadowsocks-libev_2.4.8+ds-1~bpo8+1.dsc or you can use git-buildpackage to build: gbp clone --pristine-tar https://anonscm.debian.org/git/collab-maint/shadowsocks-libev.git git checkout jessie-backports_2.4.8+ds-1 DIST=jessie-backports git-pbuilder create # Skip this if you already have pbuilder environment gbp buildpackage --git-ignore-branch --git-pristine-tar --git-pbuilder --git-dist=jessie-backports I pushed my changes to git repo: https://anonscm.debian.org/cgit/collab-maint/shadowsocks-libev.git/log/?h=jessie-backports_2.4.8+ds-1 Thank you! Cheers, -- Roger Shimizu, GMT +9 Tokyo PGP/GPG: 4096R/6C6ACD6417B3ACB1 --- End Message --- --- Begin Message --- Hi, >I am looking for a sponsor for my package "shadowsocks-libev" for >jessie-backports. sponsored G.--- End Message ---
Bug#840511: marked as done (RFS: nfft/3.3.2~rc3-1)
Your message dated Wed, 12 Oct 2016 13:08:31 + (UTC) with message-id <1276078671.7980349.1476277711...@mail.yahoo.com> and subject line Re: Bug#840511: RFS: nfft/3.3.2~rc3-1 has caused the Debian Bug report #840511, regarding RFS: nfft/3.3.2~rc3-1 to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 840511: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=840511 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "nfft" * Package name: nfft Version : 3.3.2~rc3-1 Upstream Author : Prof. Dr. Daniel Potts * URL : http://www-user.tu-chemnitz.de/~potts/nfft/ * License : GPL-2+ Section : science It builds those binary packages: libnfft3-2 - library for computing non-uniform Fourier transforms libnfft3-dev - development files for the NFFT library libnfft3-doc - documentation for the NFFT library libnfft3-double2 - library for computing non-uniform Fourier transforms (double prec libnfft3-long2 - library for computing non-uniform Fourier transforms (long-double libnfft3-single2 - library for computing non-uniform Fourier transforms (single prec To access further information about this package, please visit the following URL: https://mentors.debian.net/package/nfft Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/n/nfft/nfft_3.3.2~rc3-1.dsc Successful test builds on debomatic: http://debomatic-amd64.debian.net/distribution#unstable/nfft/3.3.2~rc3-1/buildlog Changes since the last upload: * New upstream version 3.3.2~rc3 * Upgrade to debhelper 10. - Bump compat version to 10. - Bump versioned depends on debhelper to 10. - Drop explicit dependency on dh-autoreconf. - Drop explicit usage of `--with autoreconf` from dh command. - Drop explicit usage of `--parallel` from dh command. * Refactor and simplify content of rules file. - Use dh_listpackages to detect long-double precision availability. - Drop superfluous query for DEB_HOST_ARCH_CPU. - Drop explicit setup of precision suffix, use upstream's defaults. - Simplify all targets by looping through the available precisions. * Enable testing for long-double precision for all architectures. Regards, Ghislain Vaillant --- End Message --- --- Begin Message --- Hi, >I am looking for a sponsor for my package "nfft" uploaded! BTW I don't follow why you did disable doxygen doc, but I trust your changes :) G.--- End Message ---
Bug#840526: RFS: python-gimmik/2.1-1 [ITP]
Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my package "python-gimmik" * Package name: python-gimmik Version : 2.1-1 Upstream Author : Freddie Witherden * URL : https://github.com/vincentlab/GiMMiK * License : BSD Section : python It builds those binary packages: python3-gimmik - generator of matrix multiplication kernels (Python 3) To access further information about this package, please visit the following URL: https://mentors.debian.net/package/python-gimmik Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/p/python-gimmik/python-gimmik_2.1-1.dsc Successful test build on debomatic: http://debomatic-amd64.debian.net/distribution#unstable/python-gimmik/2.1-1/buildlog Changes since the last upload: * Initial release. (Closes: #840509) Regards, Ghislain Vaillant
Bug#840500: RFS: asciinema/1.3.0-2 [RC]
Control: owner -1 ! Thnks Will take a look ASAP (either today evening or Friday) -- tobi > Package: sponsorship-requests > Severity: important > > > Hello > > I'm looking for an sponsor of my updated asciinema package > > If closes an RC bug, and various fixes/improvements > > Here is the last entry in the changelog > > asciinema (1.3.0-2) unstable; urgency=medium > > * Correct the license from MIT to GPL-3+ (Closes: #840134). > * Relicense the debian directory to GPL-3+ > * Use upstream manpage > * Run the test suite, as it does not get run by default > * Store the generated tarball using pristine-tar > > -- gustavo panizzo Tue, 11 Oct 2016 09:28:07 +0800 > > git repo can be found at > https://anonscm.debian.org/git/collab-maint/asciinema.git > > built package can be downloaded from > https://mentors.debian.net/debian/pool/main/a/asciinema/asciinema_1.3.0-2.dsc > > attached the debdiff between 1.3.0-1 and 1.3.0-2 > > > -- System Information: > Debian Release: stretch/sid > APT prefers testing > APT policy: (900, 'testing'), (300, 'unstable') > Architecture: amd64 (x86_64) > > Kernel: Linux 4.6.0-1-amd64 (SMP w/4 CPU cores) > Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) > Shell: /bin/sh linked to /bin/dash > Init: systemd (via /run/systemd/system) >
Bug#840515: RFS: open-ath9k-htc-firmware/1.4.0-25-gf6af791-1 ITP #751339
Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my package "open-ath9k-htc-firmware" * Package name: open-ath9k-htc-firmware Version : 1.4.0-25-gf6af791-1 Upstream Author : QCA * URL : https://github.com/qca/open-ath9k-htc-firmware * License : BSD-3-clause Section : misc It builds those binary packages: firmware-ath9k-htc - QCA ath9k-htc Firmware firmware-ath9k-htc-dbgsym - QCA ath9k-htc Firmware ELF file To access further information about this package, please visit the following URL: https://mentors.debian.net/package/open-ath9k-htc-firmware Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/o/open-ath9k-htc-firmware/open-ath9k-htc-firmware_1.4.0-25-gf6af791-1.dsc Regards, Oleksij Rempel Paul Fertser
Bug#840511: RFS: nfft/3.3.2~rc3-1
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "nfft" * Package name: nfft Version : 3.3.2~rc3-1 Upstream Author : Prof. Dr. Daniel Potts * URL : http://www-user.tu-chemnitz.de/~potts/nfft/ * License : GPL-2+ Section : science It builds those binary packages: libnfft3-2 - library for computing non-uniform Fourier transforms libnfft3-dev - development files for the NFFT library libnfft3-doc - documentation for the NFFT library libnfft3-double2 - library for computing non-uniform Fourier transforms (double prec libnfft3-long2 - library for computing non-uniform Fourier transforms (long-double libnfft3-single2 - library for computing non-uniform Fourier transforms (single prec To access further information about this package, please visit the following URL: https://mentors.debian.net/package/nfft Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/n/nfft/nfft_3.3.2~rc3-1.dsc Successful test builds on debomatic: http://debomatic-amd64.debian.net/distribution#unstable/nfft/3.3.2~rc3-1/buildlog Changes since the last upload: * New upstream version 3.3.2~rc3 * Upgrade to debhelper 10. - Bump compat version to 10. - Bump versioned depends on debhelper to 10. - Drop explicit dependency on dh-autoreconf. - Drop explicit usage of `--with autoreconf` from dh command. - Drop explicit usage of `--parallel` from dh command. * Refactor and simplify content of rules file. - Use dh_listpackages to detect long-double precision availability. - Drop superfluous query for DEB_HOST_ARCH_CPU. - Drop explicit setup of precision suffix, use upstream's defaults. - Simplify all targets by looping through the available precisions. * Enable testing for long-double precision for all architectures. Regards, Ghislain Vaillant
Bug#840502: RFS: shadowsocks-libev/2.4.8+ds-1~bpo8+1 -- lightweight and secure socks5 proxy
package: sponsorship-requests severity: normal X-Debbugs-Cc: rogershim...@gmail.com, max.c...@gmail.com, 073p...@gmail.com Dear mentors, I am looking for a sponsor for my package "shadowsocks-libev" for jessie-backports. * Package name: shadowsocks-libev Version : 2.4.8+ds-1~bpo8+1 Upstream Author : Max Lv * URL : https://www.shadowsocks.org * License : GPL-3+ Section : net It builds those binary packages: libshadowsocks-dev - lightweight and secure socks5 proxy (development files) libshadowsocks1 - lightweight and secure socks5 proxy (shared library) shadowsocks-libev - lightweight and secure socks5 proxy To access further information about this package, please visit the following URL: https://mentors.debian.net/package/shadowsocks-libev Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/s/shadowsocks-libev/shadowsocks-libev_2.4.8+ds-1~bpo8+1.dsc or you can use git-buildpackage to build: gbp clone --pristine-tar https://anonscm.debian.org/git/collab-maint/shadowsocks-libev.git git checkout jessie-backports_2.4.8+ds-1 DIST=jessie-backports git-pbuilder create # Skip this if you already have pbuilder environment gbp buildpackage --git-ignore-branch --git-pristine-tar --git-pbuilder --git-dist=jessie-backports I pushed my changes to git repo: https://anonscm.debian.org/cgit/collab-maint/shadowsocks-libev.git/log/?h=jessie-backports_2.4.8+ds-1 Thank you! Cheers, -- Roger Shimizu, GMT +9 Tokyo PGP/GPG: 4096R/6C6ACD6417B3ACB1
Bug#840500: RFS: asciinema/1.3.0-2 [RC]
Package: sponsorship-requests Severity: important Hello I'm looking for an sponsor of my updated asciinema package If closes an RC bug, and various fixes/improvements Here is the last entry in the changelog asciinema (1.3.0-2) unstable; urgency=medium * Correct the license from MIT to GPL-3+ (Closes: #840134). * Relicense the debian directory to GPL-3+ * Use upstream manpage * Run the test suite, as it does not get run by default * Store the generated tarball using pristine-tar -- gustavo panizzo Tue, 11 Oct 2016 09:28:07 +0800 git repo can be found at https://anonscm.debian.org/git/collab-maint/asciinema.git built package can be downloaded from https://mentors.debian.net/debian/pool/main/a/asciinema/asciinema_1.3.0-2.dsc attached the debdiff between 1.3.0-1 and 1.3.0-2 -- System Information: Debian Release: stretch/sid APT prefers testing APT policy: (900, 'testing'), (300, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 4.6.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) diff -Nru asciinema-1.3.0/debian/asciinema.manpages asciinema-1.3.0/debian/asciinema.manpages --- asciinema-1.3.0/debian/asciinema.manpages 2016-07-29 17:06:45.0 +0800 +++ asciinema-1.3.0/debian/asciinema.manpages 2016-10-11 09:23:16.0 +0800 @@ -1 +1 @@ -debian/asciinema.1 +man/asciinema.1 diff -Nru asciinema-1.3.0/debian/changelog asciinema-1.3.0/debian/changelog --- asciinema-1.3.0/debian/changelog 2016-07-29 18:37:47.0 +0800 +++ asciinema-1.3.0/debian/changelog 2016-10-11 09:28:07.0 +0800 @@ -1,3 +1,13 @@ +asciinema (1.3.0-2) unstable; urgency=medium + + * Correct the license from MIT to GPL-3+ (Closes: #840134). + * Relicense the debian directory to GPL-3+ + * Use upstream manpage + * Run the test suite, as it does not get run by default + * Store the generated tarball using pristine-tar + + -- gustavo panizzo Tue, 11 Oct 2016 09:28:07 +0800 + asciinema (1.3.0-1) unstable; urgency=medium * New upstream release diff -Nru asciinema-1.3.0/debian/control asciinema-1.3.0/debian/control --- asciinema-1.3.0/debian/control 2016-07-29 23:20:15.0 +0800 +++ asciinema-1.3.0/debian/control 2016-10-11 09:28:07.0 +0800 @@ -2,7 +2,7 @@ Section: utils Priority: optional Maintainer: gustavo panizzo -Build-Depends: debhelper (>= 9), python3-setuptools, dh-python, python3-all +Build-Depends: debhelper (>= 9), python3-setuptools, dh-python, python3-all, python3-nose Standards-Version: 3.9.8 Vcs-Browser: https://anonscm.debian.org/cgit/collab-maint/asciinema.git Vcs-Git: https://anonscm.debian.org/git/collab-maint/asciinema.git diff -Nru asciinema-1.3.0/debian/copyright asciinema-1.3.0/debian/copyright --- asciinema-1.3.0/debian/copyright 2016-07-29 18:11:46.0 +0800 +++ asciinema-1.3.0/debian/copyright 2016-10-11 09:28:07.0 +0800 @@ -3,29 +3,27 @@ Source: http://asciinema.org Files: * -Copyright: (c) 2013-2016, Marcin Kulik -License: MIT +Copyright: 2013-2016, Marcin Kulik +License: GPL-3+ Files: debian/* -Copyright: (c) 2014-2016, gustavo panizzo -License: MIT +Copyright: 2014-2016, gustavo panizzo +License: GPL-3+ -License: MIT - Permission is hereby granted, free of charge, to any person obtaining - a copy of this software and associated documentation files (the - "Software"), to deal in the Software without restriction, including - without limitation the rights to use, copy, modify, merge, publish, - distribute, sublicense, and/or sell copies of the Software, and to - permit persons to whom the Software is furnished to do so, subject to - the following conditions: +License: GPL-3+ + This program is free software; you can redistribute it and/or modify + it under the terms of the GNU General Public License as published by + the Free Software Foundation; either version 3 of the License, or + (at your option) any later version. . - The above copyright notice and this permission notice shall be - included in all copies or substantial portions of the Software. + This program is distributed in the hope that it will be useful, + but WITHOUT ANY WARRANTY; without even the implied warranty of + MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + GNU General Public License for more details. . - THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, - EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF - MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND - NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE - LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION - OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION - WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. + You should have received a copy of the GNU General Public License + along with this program; if not, write to the Free Software + Foundatio
