Re: Introducting Debian Trends: historical graphs about Debian packaging practices, and "packages smells"
On Mon, Apr 15, 2019 at 05:35:40PM +0200, Bastian Blank wrote: > On Mon, Apr 15, 2019 at 04:55:12PM +0200, Andreas Tille wrote: > > biococoa (U) does not use Debhelper (no compat level found) > > (source version: 2.2.2-4) > > biococoa (U) should switch to dh. Current build system: cdbs > > (source version: 2.2.2-4) > > | % grep cdbs -r biococoa-2.2.2 > | biococoa-2.2.2/debian/rules:include /usr/share/cdbs/1/rules/gnustep.mk > | biococoa-2.2.2/debian/rules:include /usr/share/cdbs/1/class/gnumakefile.mk > | biococoa-2.2.2/debian/control:Build-Depends: cdbs, > | biococoa-2.2.2/debian/changelog: dh_installsystemd instead -> that's a > cdbs issue) > | biococoa-2.2.2/debian/changelog: * debian/control (Build-Depends): Add > cdbs and quilt. Drop gnustep-make This explains the cdbs smelling (and I loved to get rid of this but this needs to be fixed by gnustep.mk). But in how far is "no compat level found" sensible? Kind regards Andreas. -- http://fam-tille.de
Re: native packages? (Re: Introducting Debian Trends: historical graphs about Debian packaging practices, and "packages smells")
Hi, On 15.04.19 21:23, Marco d'Itri wrote: > Generating an upstream tarball in this case is still useful because this > way we do not need to upload and store forever the full source archive > every time that something changes only in the packaging. That, and upstream tarballs generated with "git archive" have a magic comment tag that says which revision was used to build them, so we don't even lose information. $ git archive --format=tar HEAD | git get-tar-commit-id 973188bd3b4628646c53ca9ab9bf71cc95eadd43 Simon signature.asc Description: OpenPGP digital signature
Re: native packages? (Re: Introducting Debian Trends: historical graphs about Debian packaging practices, and "packages smells")
On Apr 15, Sam Hartman wrote: > However if my sources are in git, git is the definitive format for > thinking about things, and the dsc I'm producing is only for the > convenience of the archive, I don't want to deal with an upstream > tarball. Generating an upstream tarball in this case is still useful because this way we do not need to upload and store forever the full source archive every time that something changes only in the packaging. -- ciao, Marco signature.asc Description: PGP signature
Bug#927170: RFP: jadx -- Android Dex decompiler
Package: wnpp Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org Package name: jadx Version: 0.9.0 Upstream Author: Skylot URL: https://github.com/skylot/jadx License: Apache-2.0 Description: Android Dex decompiler Jadx is a decompiler for Android Dex files. When given an Android APK package, Jadx tries to extract all resources, including the Dex file (i.e., the file containing the Java classes belonging to that package), and tries to decompile the stored classes to high level Java code. It is very useful for the reverse engineering of Android packages. Thanks, Giovanni. -- Giovanni Mascellani Postdoc researcher - Université Libre de Bruxelles signature.asc Description: OpenPGP digital signature
Re: native packages? (Re: Introducting Debian Trends: historical graphs about Debian packaging practices, and "packages smells")
> "Holger" == Holger Levsen writes: Holger> On Sat, Apr 13, 2019 at 01:48:01PM +0100, Simon McVittie wrote: >> On Sat, 13 Apr 2019 at 10:04:10 +, Holger Levsen wrote: >> > I see no point whatsoever in 3.0 (native). The main advantage >> of 3.0 (native) is that it makes it explicit that the package is >> deliberately native [...] Holger> ok, sorry, I ment to say: I see no point whatsoever in Holger> native packages. AFAICS there are no advantages, just Holger> downsides. I work on a lot of packages that don't really produce upstream tarballs. It's painful and makes the workflow less fun to have to go deal with upstream tarballs myself and I don't think it adds anything to the workflow. Upstream tarballs are perhaps nice if upstream actually produces them (although I think even that is a discussion we may want to have long-term as we move everything to git). However if my sources are in git, git is the definitive format for thinking about things, and the dsc I'm producing is only for the convenience of the archive, I don't want to deal with an upstream tarball. This is even more true if I happen to be using dgit. --Sam
Re: Introducting Debian Trends: historical graphs about Debian packaging practices, and "packages smells"
On 15/04/19 at 16:55 +0200, Andreas Tille wrote: > Are you sure that you are not tricked by false positives from lintian? I might be, but if lintian reports something incorrectly about your package, it's probably worth fixing in lintian. Lucas
Re: Introducting Debian Trends: historical graphs about Debian packaging practices, and "packages smells"
On Mon, Apr 15, 2019 at 04:55:12PM +0200, Andreas Tille wrote: > biococoa (U) does not use Debhelper (no compat level found) > (source version: 2.2.2-4) > biococoa (U) should switch to dh. Current build system: cdbs > (source version: 2.2.2-4) | % grep cdbs -r biococoa-2.2.2 | biococoa-2.2.2/debian/rules:include /usr/share/cdbs/1/rules/gnustep.mk | biococoa-2.2.2/debian/rules:include /usr/share/cdbs/1/class/gnumakefile.mk | biococoa-2.2.2/debian/control:Build-Depends: cdbs, | biococoa-2.2.2/debian/changelog: dh_installsystemd instead -> that's a cdbs issue) | biococoa-2.2.2/debian/changelog: * debian/control (Build-Depends): Add cdbs and quilt. Drop gnustep-make Regards, Bastian -- Military secrets are the most fleeting of all. -- Spock, "The Enterprise Incident", stardate 5027.4
Re: Introducting Debian Trends: historical graphs about Debian packaging practices, and "packages smells"
On Sat, Apr 13, 2019 at 03:46:57PM +0200, gregor herrmann wrote: > On Sat, 13 Apr 2019 10:20:53 +0200, Lucas Nussbaum wrote: > > > TL;DR: see https://trends.debian.net and > > https://trends.debian.net/#smells > > Very nice, thank you. +1 I like it a lot! > > [4] https://trends.debian.net/smells-dd-list.txt As far as I understood you are using lintian results. However, the real packaging does not (always) reflect this. At least I've found an example. Link [4] lists: biococoa (U) does not use Debhelper (no compat level found) (source version: 2.2.2-4) biococoa (U) should switch to dh. Current build system: cdbs (source version: 2.2.2-4) However: $ apt-get source biococoa $ cd biococoa-2.2.2/ $ cat debian/compat 10 $ grep debhelper debian/control debhelper (>= 11~), Are you sure that you are not tricked by false positives from lintian? Kind regards and thanks a lot for this great effort. Andreas. -- http://fam-tille.de
Re: Golang >= 1.12 in Buster?
On 4/14/19 1:00 PM, Toni Mueller wrote: > Or how about removing Python2 altogether, then? That's actually not a bad idea, which we considered, and only postponed until Buster is out. FYI, I already started removing Python 2 support in many of the packages I maintain (currently only uploaded to Experimental though...). Thomas Goirand (zigo)
Re: Golang >= 1.12 in Buster?
On 4/15/19 9:24 AM, Hideki Yamane wrote: > On Sun, 14 Apr 2019 21:11:09 +0200 > "Dr. Tobias Quathamer" wrote: >> I think it's the right decision of the release team to stick with golang >> 1.11 for buster. The previous migration from golang 1.10 to 1.11 took us >> about four weeks until we had fixed all packages with new FTBFS bugs. > > Can we migrate that from backports -> proposed-updates -> point release? Since when do we use backports as a mean to reach Stable? Cheers, Thomas Goirand (zigo)
Re: Golang >= 1.12 in Buster?
On Sun, 14 Apr 2019 21:11:09 +0200 "Dr. Tobias Quathamer" wrote: > I think it's the right decision of the release team to stick with golang > 1.11 for buster. The previous migration from golang 1.10 to 1.11 took us > about four weeks until we had fixed all packages with new FTBFS bugs. Can we migrate that from backports -> proposed-updates -> point release? -- Hideki Yamane
