Entry to GSoC 2021
Hello, My name is Aditya Pratap Singh, and I am a BTech fresher at Indraprastha Institute of Information Technology, Delhi. I have a decent experience in C++ and Python. I've been using Arch for a month now. Prior to that, I'd used Debian for over a year. I am very much interested in participating in GSoC 2021. The main reason for doing GSoC is to get exposure to the developer's world and work with new people. I hope that, despite me being a fresher, the Debian community welcomes me. I am looking forward to working with Debian. -- Regards, Aditya
Bug#981705: RFS: proxycheck/0.49a-6 [QA] -- checks existence of open proxy
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "proxycheck": * Package name : proxycheck Version : 0.49a-6 Upstream Author : [fill in name and email of upstream] * URL : http://www.corpit.ru/mjt/proxycheck.html * License : GPL-2+ * Vcs : [fill in URL of packaging vcs] Section : net It builds those binary packages: proxycheck - checks existence of open proxy To access further information about this package, please visit the following URL: https://mentors.debian.net/package/proxycheck/ Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/p/proxycheck/proxycheck_0.49a-6.dsc Changes since the last upload: proxycheck (0.49a-6) unstable; urgency=medium . * QA upload. * Set Debian QA Group as maintainer. (see #980955) * Using new DH level format. Consequently: - debian/compat: removed. - debian/control: changed from 'debhelper' to 'debhelper-compat' in Build-Depends field and bumped level to 13. * debian/control: - Set Rules-Requires-Root:no. - Bumped Standards-Version to 4.5.1. - Set section and priority fields matching override. * debian/copyright: Add dep5 copyright. * debian/watch: Use uscan version 4. Regards,
Bug#981702: RFS: privacybadger/2021.2.2-1 -- browser extension automatically learns to block invisible trackers
Package: sponsorship-requests Severity: normal X-Debbugs-CC: pkg-mozext-maintain...@lists.alioth.debian.org Dear mentors, I am looking for a sponsor for my package "privacybadger": * Package name: privacybadger Version : 2021.2.2-1 Upstream Author : Electronic Frontier Foundation * URL : https://www.eff.org/privacybadger/ * License : GPL-3+ Section : web It builds those binary packages: webext-privacy-badger - browser extension automatically learns to block invisible trackers To access further information about this package, please visit the following URL: https://mentors.debian.net/package/privacybadger/ Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/p/privacybadger/privacybadger_2021.2.2-1.dsc Changes since the last upload: privacybadger (2021.2.2-1) unstable; urgency=medium . * Friendly takeover back into the WebExt team. * New upstream release. -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (500, 'testing'), (2, 'unstable'), (1, 'testing-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-2-amd64 (SMP w/2 CPU threads) Kernel taint flags: TAINT_USER, TAINT_WARN, TAINT_FIRMWARE_WORKAROUND Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled signature.asc Description: This is a digitally signed message part.
Re: fix severe bug in my package
never mind :) as there are no packages at the moment, there is no link. sorry for the noise, Aaron On Tue, Feb 2, 2021 at 6:53 PM Aaron Boxer wrote: > > On Tue, Feb 2, 2021 at 3:22 PM Aaron Boxer wrote: > >> I've uploaded a new 7.6.6 version to the mentors site with a fix for this >> issue >> >> https://mentors.debian.net/package/libgrokj2k/ >> >> I see there isn't a soft freeze until Feb 12, so hopefully this can be >> migrated before that deadline. >> >> Thanks! >> Aaron >> > > Thanks a lot for uploading! One odd thing: it looks like > > https://mentors.debian.net/package/libgrokj2k/ > > is no more: I can no longer view the page. > > Cheers, > Aaron > > > >> >> On Tue, Feb 2, 2021 at 9:03 AM Aaron Boxer wrote: >> >>> Dear Mentors, >>> Last night I discovered a severe bug in my encoder. The bug affects lossy >>> compression of monochrome images, a very large class of images. The bug >>> causes the output pixels to be set to 0, which is pretty serious. >>> >>> I realize there is a freeze on new packages leading up to Bullseye >>> release, but >>> is there a way of getting a new version in somehow? I wouldn't want the >>> current >>> version to be released. >>> >>> Thanks very much, >>> Aaron >>> >>
Re: fix severe bug in my package
On Tue, Feb 2, 2021 at 3:22 PM Aaron Boxer wrote: > I've uploaded a new 7.6.6 version to the mentors site with a fix for this > issue > > https://mentors.debian.net/package/libgrokj2k/ > > I see there isn't a soft freeze until Feb 12, so hopefully this can be > migrated before that deadline. > > Thanks! > Aaron > Thanks a lot for uploading! One odd thing: it looks like https://mentors.debian.net/package/libgrokj2k/ is no more: I can no longer view the page. Cheers, Aaron > > On Tue, Feb 2, 2021 at 9:03 AM Aaron Boxer wrote: > >> Dear Mentors, >> Last night I discovered a severe bug in my encoder. The bug affects lossy >> compression of monochrome images, a very large class of images. The bug >> causes the output pixels to be set to 0, which is pretty serious. >> >> I realize there is a freeze on new packages leading up to Bullseye >> release, but >> is there a way of getting a new version in somehow? I wouldn't want the >> current >> version to be released. >> >> Thanks very much, >> Aaron >> >
Re: fix severe bug in my package
I've uploaded a new 7.6.6 version to the mentors site with a fix for this issue https://mentors.debian.net/package/libgrokj2k/ I see there isn't a soft freeze until Feb 12, so hopefully this can be migrated before that deadline. Thanks! Aaron On Tue, Feb 2, 2021 at 9:03 AM Aaron Boxer wrote: > Dear Mentors, > Last night I discovered a severe bug in my encoder. The bug affects lossy > compression of monochrome images, a very large class of images. The bug > causes the output pixels to be set to 0, which is pretty serious. > > I realize there is a freeze on new packages leading up to Bullseye > release, but > is there a way of getting a new version in somehow? I wouldn't want the > current > version to be released. > > Thanks very much, > Aaron >
Bug#981621: RFS: filezilla/3.52.2+dfsg-3 [Team] -- Full-featured graphical FTP/FTPS/SFTP client
On Tue, 2021-02-02 at 10:53 +0100, Gianfranco Costamagna wrote: > Hello Philip, > > while we like to remove non-free stuff from our tarballs, I don't > think removing dlls is a good use case. > > Using the upstream tarball is quite convenient, since we have less > importing errors, the md5 is the same > and can be verified, and we don't introduce patches that last > forever. > > DLL files are not used in our build process, so they are not > impacting in any way the resulting deb file. > > Do you think this repack is really worth? > > I know sometimes we want to silence lintian, but the cost might just > be too high for a little gain. > > I would like to know if anybody else has a different opinion, please > share it with me! > > thanks for caring about DFSG-ness of the package! > > Gianfranco > Hi Gianfranco, I had a feeling the DFSG and lintian changes maybe questioned, though they are in-line with policy. For this reason I prepared a package backup pre making these changes. :-) Certain DFSG lintian warnings do possibly need discussion around them and if they should be strictly adhered to. I will upload a version without the contentious changes and we can go from there. Regards Phil -- *** Playing the game for the games own sake. *** WWW: https://kathenas.org Twitter: @kathenasorg IRC: kathenas GPG: 724AA9B52F024C8B signature.asc Description: This is a digitally signed message part
Debian Policy and copyright for binary packages made from foo-source
Hello, I'm working on packaging binutils-sh-elf, which is a native package which only has a debian/ directory. At build time, it extracts the tarball from binutils- source—whatever version it happens to be—and builds it into binary packages with the appropriate options. For informative purposes, I have this notice in my debian/copyright file: Comment: This file specifies licensing information only for the source package, which merely provides the tooling for the sh-elf port. For licensing information about the GNU Binutils binaries, consult /usr/share/doc/binutils-common/copyright. This seems like a convenient solution that satisfies the spirit of Debian Policy, since I recommend binutils-common for the translations anyway. This doesn't feel much different from referring to /usr/share/common-licenses/. However Policy seems to say I ought to include the notices directly: > However, the copyright notices for any files which are compiled into the > object code shipped in the binary package must all be included in > /usr/share/doc/PACKAGE/copyright when the license requires that copyright > information be included in all copies and/or binary distributions, as most > do. I could concatenate my /usr/share/doc/pkg/copyright with the one for the Binutils source, but then I'd have to give up having a machine-readable copyright file since Binutils doesn't have one, and also seems convoluted. Does it seem like my comment in my copyright file may satisfy the intent, or that I still need to mangle the file? Similar packages don't seem to be as meticulous on this issue. signature.asc Description: This is a digitally signed message part.
Re: fix severe bug in my package
On Tue, 2021-02-02 at 09:08 -0500, Aaron Boxer wrote: > Forgot to mention: this is the package in question: > > https://tracker.debian.org/pkg/libgrokj2k > > On Tue, Feb 2, 2021 at 9:03 AM Aaron Boxer wrote: > > Dear Mentors, > > Last night I discovered a severe bug in my encoder. The bug affects lossy > > compression of monochrome images, a very large class of images. The bug > > causes the output pixels to be set to 0, which is pretty serious. > > > > I realize there is a freeze on new packages leading up to Bullseye release, > > but > > is there a way of getting a new version in somehow? I wouldn't want the > > current > > version to be released. > > > > Thanks very much, > > Aaron You are allowed everything as described on https://release.debian.org/bullseye/freeze_policy.html (It's still 10 days to the soft freeze, so new versions are generally acceptable unless you need to trigger a library transistion. If it is a good idea to have a new upstream version at that point of time is a different story and depends a bit on the amount of changes done… You probably in the best situation to judge that) Adding/removing binary packages would be allowed, (beside library transistions), but need to clear NEW until Feb 12, so this is risky (I'd recommend going to experimental for NEW clearing because of that.) You probably want create a targeted fix only against the version currently in unstable. This might be also less risky than a new upstream version… -- tobi
Re: Does 32-bit arithmetic overflow mean arch incompatibility?
Hi Robin, On 2021-01-29 23:56, Robin Gustafsson wrote: > Does the possibility of arithmetic overflow on 32-bit systems mean > that the software is to be considered incompatible with 32-bit > architectures? > > A package I'm working on has some test failures on 32-bit due to > overflows. I only maintain architecture-independent packages and I'm > not sure how this scenario would usually be treated. I would say yes. The upstream most likely would confirm that. Best, Andrius
Re: fix severe bug in my package
Forgot to mention: this is the package in question: https://tracker.debian.org/pkg/libgrokj2k On Tue, Feb 2, 2021 at 9:03 AM Aaron Boxer wrote: > Dear Mentors, > Last night I discovered a severe bug in my encoder. The bug affects lossy > compression of monochrome images, a very large class of images. The bug > causes the output pixels to be set to 0, which is pretty serious. > > I realize there is a freeze on new packages leading up to Bullseye > release, but > is there a way of getting a new version in somehow? I wouldn't want the > current > version to be released. > > Thanks very much, > Aaron >
fix severe bug in my package
Dear Mentors, Last night I discovered a severe bug in my encoder. The bug affects lossy compression of monochrome images, a very large class of images. The bug causes the output pixels to be set to 0, which is pretty serious. I realize there is a freeze on new packages leading up to Bullseye release, but is there a way of getting a new version in somehow? I wouldn't want the current version to be released. Thanks very much, Aaron
Bug#981622: RFS: awstats/7.8-2 [QA] [RC] -- powerful and featureful web server log analyzer
Package: sponsorship-requests Severity: important Dear mentors, I am looking for a sponsor for my package "awstats": * Package name: awstats Version : 7.8-2 Upstream Author : Laurent Destailleur * URL : http://awstats.sourceforge.net/ * License : Apache-2.0, GPL-1+, GPL-3+, CC-BY-3.0 * Vcs : https://salsa.debian.org/debian/awstats Section : web It builds those binary packages: awstats - powerful and featureful web server log analyzer To access further information about this package, please visit the following URL: https://mentors.debian.net/package/awstats/ Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/a/awstats/awstats_7.8-2.dsc Changes since the last upload: awstats (7.8-2) unstable; urgency=high . * QA upload. * CVE-2020-35176: in AWStats through 7.8, cgi-bin/awstats.pl?config= accepts a partial absolute pathname (omitting the initial /etc), even though it was intended to only read a file in the /etc/awstats/awstats.conf format. NOTE: this issue exists because of an incomplete fix for CVE-2017-1000501 and CVE-2020-29600. Closes: #977190 This only adds an upstream patch to close a CVE Regards, Håvard
Bug#981632: RFS: materia-gtk-theme/20200916-0.1 [NMU] -- Material Design theme for GNOME/GTK+ based desktop environments
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "materia-gtk-theme": * Package name: materia-gtk-theme Version : 20200916-0.1 Upstream Author : [fill in name and email of upstream] * URL : https://github.com/nana-4/materia-theme * License : GPL-2+, LGPL-2.1 * Vcs : https://salsa.debian.org/isaagar-guest/materia-gtk-theme Section : x11 It builds those binary packages: materia-gtk-theme - Material Design theme for GNOME/GTK+ based desktop environments To access further information about this package, please visit the following URL: https://mentors.debian.net/package/materia-gtk-theme/ Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/m/materia-gtk-theme/materia-gtk-theme_20200916-0.1.dsc Changes since the last upload: materia-gtk-theme (20200916-0.1) unstable; urgency=medium . * Non-maintainer upload. * New upstream release. * debian/control: - Added in Build-Depends meson and sassc. * debian/rules: - Fixed FTBFS and add support to build system with meson. * Fixed support for Gnome 3.38. (Closes: #978965) Regards, -- Leandro Cunha
Re: Platformer game package - "Super Bombinhas"
Hi Paul, Thank you again for the answers. I will surely take most of your suggestions into account to improve the quality of my project. Answering your questions: > The game appears to be GNU GPLv3 and CC-BY-SA-4.0 rather than MIT licensed. You're right. I confused it because it used to be MIT, but I changed it a while ago. > I thought Ruby could load code from multiple files, maybe using modules or similar, so deb.sh and bundle.rb probably are unnecessary? bundle.rb is still useful for the way I currently create an executable for Windows. deb.sh would still be useful to copy the files to the package structure (or is there a better way to do this?) > I wonder about where the res/alevaLogo.svg file came from, what it refers to and what the license is. It also doesn't appear to be used anywhere in the codebase? It's no longer used, I removed the "Aleva Games" name from the project and decided to launch it under my own name. By the way, none of the SVG files in the project are being used. They are remainders from long ago, when the game's graphics weren't even pixel art... I will remove them. > I note that data/img/ui/minigl.png was rendered from Inkscape but there is no corresponding minigl.svg file. It also doesn't appear to be used anywhere in the codebase? It's the logo from my engine, I don't see the point in including the original SVG file in the project. It is used in the code, referenced as ":minigl" (because of how my engine works, it assumes PNG as the default extension). > How were the audio files in data/sound/ created? I downloaded most of them from freesound.org, edited some of them myself on Audacity. > How were the audio files in data/song/ created? They were all composed by other people and exported to me as OGG. I don't know exactly what technologies they used, one of them I know used Ardour 6, but possibly also other software. > How were the audio files in res/song/ created? They were created in Linux Multimedia Studio. However, they are also no longer used, I will remove them from the project. > There is a typo in elements.rb, replace "seciton" with "section". Thanks for pointing that out! I already fixed it. > There are a few duplicate files, run this command to find them: fdupes -q -r The only duplicates I found besides the files that were copied to the "deb" folder are the README files inside the assets folders, which is expected since they only contain the license info, and some images used both in the "data/img/icon" and "data/img/sprite" folders, but that is intended (these are used in different ways in the code). Regarding the other points I have no commentary. Some of them I will probably act upon before generating the package. Thanks, Victor Em seg., 1 de fev. de 2021 às 23:47, Paul Wise escreveu: > On Mon, 2021-02-01 at 08:36 -0300, Victor David Santos wrote: > > > Thanks for the detailed feedback. Just to make sure, not all of these > > items you pointed out are mandatory for the package to be accepted, > > right? > > All of the points I made are my personal opinions. There are a range of > different approaches to the things I brought up within Debian and > opinions on them vary widely. I don't generally sponsor packages so my > opinions don't really matter here and I expect there are plenty of > folks who would not require any of the changes I suggested. I only post > my opinions in order to try to influence people to do things in what I > see as a way to mitigate lots of downsides of certain practices. > > > For example, the fact that my font image doesn't support all > > character sets. It's not viable for me to make it support all of > > them, instead I would update it on demand as new translations were > > made... > > An alternative approach would be to render text from the system fonts > at runtime, that would give you support for every language with fonts. > That might not fit with your design philosophy though, so perhaps it is > best to stick the current approach of hand-drawn pixel fonts for now. > > > If you could point out to me which of these are changes I must do, > > that would help a lot... I don't have as much time to dedicate to > > this project as I would like. :/ > > Reading through the intro guide, creating a Debian source package > (rather than just a .deb) and packaging gosu/minigl are the only things > you must do. Answers to the questions I asked would not take long to do > and would be useful to have. > > > The Gosu library is not owned by me, so how would I proceed to have > > it packaged for Debian? Is it really necessary, considering that it's > > a Ruby gem, publicly available from rubygems.org? > > Each dependency must be separately packaged in Debian properly with a > new source package (.dsc) and one or more binary packages (.deb). > > Personally I would suggest packaging them from the upstream source on > GitHub rather than from the Ruby gem files. That isn't mandatory for > Debian packages of Ruby projects though. > >
Bug#981627: RFS: dt-utils/2019.01.0+ds-1 [ITP] -- Device tree and barebox related tools
Package: sponsorship-requests Severity: wishlist Control: block 965234 by -1 Dear mentors, I am looking for a sponsor for my package "dt-utils": * Package name: dt-utils Version : 2019.01.0+ds-1 Upstream Author : Pengutronix * License : GPL-2 * Vcs : https://salsa.debian.org/bage/dt-utils Section : kernel It builds those binary packages: libdt-utils-dev - Device tree related library (development files) libdt-utils4 - Device tree related library dt-utils - Device tree and barebox related tools To access further information about this package, please visit the following URL: https://mentors.debian.net/package/dt-utils/ Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/d/dt-utils/dt-utils_2019.01.0+ds-1.dsc Changes for the initial release: dt-utils (2019.01.0+ds-1) unstable; urgency=medium . * Initial release (Closes: #965234) Regards, Bastian
Bug#981621: RFS: filezilla/3.52.2+dfsg-3 [Team] -- Full-featured graphical FTP/FTPS/SFTP client
Hello Philip, while we like to remove non-free stuff from our tarballs, I don't think removing dlls is a good use case. Using the upstream tarball is quite convenient, since we have less importing errors, the md5 is the same and can be verified, and we don't introduce patches that last forever. DLL files are not used in our build process, so they are not impacting in any way the resulting deb file. Do you think this repack is really worth? I know sometimes we want to silence lintian, but the cost might just be too high for a little gain. I would like to know if anybody else has a different opinion, please share it with me! thanks for caring about DFSG-ness of the package! Gianfranco
Bug#981621: RFS: filezilla/3.52.2+dfsg-3 [Team] -- Full-featured graphical FTP/FTPS/SFTP client
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "filezilla": * Package name: filezilla Version : 3.52.2+dfsg-3 Upstream Author : Tim Kosse * URL : https://filezilla-project.org/ * License : MIT, GPL-2+, BSD-like, CC0-1.0, permissive * Vcs : https://salsa.debian.org/debian/filezilla Section : net It builds those binary packages: filezilla-common - Architecture independent files for filezilla filezilla - Full-featured graphical FTP/FTPS/SFTP client To access further information about this package, please visit the following URL: https://mentors.debian.net/package/filezilla/ Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/f/filezilla/filezilla_3.52.2+dfsg-3.dsc Changes since the last upload: filezilla (3.52.2+dfsg-3) unstable; urgency=medium . [Phil Wyett] * Team upload * DFSG - Exclude files from debian archive tarball - Removal of Windows DLL files - Removal of autogenerated Visual Studio resource.h file - Add 02_dfsg-remove-windows-file-entries.patch * Add some lintian overrides to d/filezilla.lintian-overrides . [Pino Toscano] * Remove creation of no longer required XPM image(s) - Remove imagemagick Build-Depends - Remove conversion to XPM from d/rules - Remove link for /usr/share/pixmaps/* Regards Phil -- *** Playing the game for the games own sake. *** WWW: https://kathenas.org Twitter: @kathenasorg IRC: kathenas GPG: 724AA9B52F024C8B signature.asc Description: This is a digitally signed message part
