Re: debian/gbp.cnf analytics? (Re: Re: Accepting DEP14?)
Hi Otto Getting the list of source packages with a particular file in them can be done by apt-file (see "--index-names dsc"). sources.debian.org can provide single files - you need an API call to find the correct URL for the file first. I don't know if the service admins would get upset at 1655 files being downloaded in the following fashion. apt-file search --index-names dsc --package-only debian/gbp.conf | while read pkg; do echo -n $pkg url=$(curl -s https://sources.debian.org/api/src/zzuf/0.15-4/debian/gbp.conf/ | jq -r .raw_url) curl -s https://sources.debian.org/$url > $pkg echo . done (takes 1-2s per source package it seems) sources.d.o can also do lookups by file sha256sum. The simple 2-line gbp.conf that sets debian/master is in 183 source packages according to: https://sources.debian.org/api/sha256/?checksum=c4a26b58ec236eab6919435af0267c29840191a97beeb3caa4712e42a6d51be8 which might permit some pre-filtering of the list of packages to inspect. regards Stuart -- Stuart Prescott http://www.nanonanonano.net/ stu...@nanonanonano.net Debian Developer http://www.debian.org/ stu...@debian.org GPG fingerprint 90E2 D2C1 AD14 6A1B 7EBB 891D BBC1 7EBB 1396 F2F7
Re: debian/gbp.cnf analytics? (Re: Re: Accepting DEP14?)
For those playing along at home... On 19/08/2024 14:53, Stuart Prescott wrote: url=$(curl -s https://sources.debian.org/api/src/zzuf/0.15-4/debian/gbp.conf/ | jq -r .raw_url) The API URL should obviously be https://sources.debian.org/api/src/$pkg/latest/debian/gbp.conf/ and curl will also need -L to follow the redirect from 'latest' to the specific version: url=$(curl -sL https://sources.debian.org/api/src/$pkg/latest/debian/gbp.conf/ | jq -r .raw_url) -- Stuart Prescott http://www.nanonanonano.net/ stu...@nanonanonano.net Debian Developer http://www.debian.org/ stu...@debian.org GPG fingerprint 90E2 D2C1 AD14 6A1B 7EBB 891D BBC1 7EBB 1396 F2F7
Bug#431905: ITP: latexdraw -- vector drawing program for LaTeX using PSTricks
Package: wnpp Severity: wishlist Owner: Stuart Prescott <[EMAIL PROTECTED]> * Package name: latexdraw Version : 1.9.3 Upstream Author : Arnaud BLOUIN <[EMAIL PROTECTED]> * URL : http://latexdraw.sourceforge.net/ * License : GPL Programming Lang: Java Description : vector drawing program for LaTeX using PSTricks LaTeXDraw is a free PSTricks code generator or PSTricks editor for LaTeX. It has the usual drawing tools (lines, rectangles, circles, Bezier curves) and can resize, rotate, move and join objects using vector transformations. Figures can be exported as PSTricks code, eps, jpg, bmp, png, ppm. PSTricks in an extension of LaTeX which allows the creation of drawings, diagrams and graphs in 2D or 3D. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#431907: ITP: java-imaging-utilities -- library to load, analyze, process and save pixel images and sample application
Package: wnpp Severity: wishlist Owner: Stuart Prescott <[EMAIL PROTECTED]> * Package name: java-imaging-utilities Version : 0.14.2 Upstream Author : Marco Schmidt <[EMAIL PROTECTED]> * URL : http://schmidt.devlib.org/jiu/` * License : GPL Programming Lang: Java Description : library to load, analyze, process and save pixel images and sample application This package is a dependency of latexdraw (see #431905). Three packages from this source package: libjiu-java: JIU, the Java Imaging Utilities, is a library which offers functionality to load, analyze, process and save pixel images. It can handle a variety of different image formats (PBM, PNG, GIF, TIFF, PSD etc) and perform a number of sophisticated transformations to the images including color adjustments, analysis and image filtering. java-imaging-utilities: Demonstration programs that come with the java-imaging-utilities library, found in package libjiu-java. java-imaging-utilities-doc: JIU, the Java Imaging Utilities, is a library which offers functionality to load, analyze, process and save pixel images. This package contains the API documentation for the library. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#431908: ITP: libwmfview-java -- library to load and display wmf images
Package: wnpp Severity: wishlist Owner: Stuart Prescott <[EMAIL PROTECTED]> * Package name: libwmfview-java Version : 0.8.1 Upstream Author : Marco Schmidt <[EMAIL PROTECTED]> * URL : http://latexdraw.sf.net/ * License : GPL Programming Lang: Java Description : library to load and display wmf images This package is a dependency of latexdraw (see #431905). Provides a GPL java library to permit Java AWT applications to display Windows Meta File (WMF) images. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#447525: ITP: jlibeps -- Java library to create EPS images
Package: wnpp Severity: wishlist Owner: Stuart Prescott <[EMAIL PROTECTED]> * Package name: jlibeps Version : 0.1.0 Upstream Author : Arnaud BLOUIN <[EMAIL PROTECTED]> * URL : http://jlibeps.sourceforge.net/ * License : GPLv2 or later Programming Lang: Java Description : Java library to create EPS images The jlibeps classes are a set of Java classes for creating EPS images. They are suitable for creating high quality EPS graphics for use in documents and papers, and can be used just like a standard Graphics2D object within Java applications that are using AWT. jlibeps is a fork of the last GPL version of the EpsGraphics2D package from jibble.org. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: systemd now appears to be only possible init system in testing
Hi Norbert, Please remember these arguments you have been making next time you make what you believe are perfectly justified changes to the texlive packaging by (once again) introducing new and incompatible versions of sty files or moving files between packages. I'm sure the texlive maintainers feel perfectly justified in breaking existing setups and causing packages to FTBFS by doing this. I'm sure you can explain to me that it's all much better for the changes, even though it looks like it only makes work for me. I understand that to a large extent your hands are tied because you need to track upstream releases and you can't hold a style file at an ancient version forever just to make sure that nothing gets broken. Because I trust the texlive maintainers to be fundamentally doing the right things for Debian, I don't reassign all the bugs you cause to the texlive packages because they were the ones that broke their reverse-dependencies. Rather, I spend the time to adapt to the new way. Similarly, I don't rant on mailing lists about how the world is going to end because of this breakage. I don't make insinuations about the competence of the texlive maintainers when I don't understand why they have done something. I don't belittle your work. I don't run around complaining that your approach to texlive is a giant conspiracy. The same is true for a package like systemd-shim which would permit you to use the packages you talked about without running systemd. systemd-shim has to adapt to the changing landscape around it and it is the responsibility of its authors (NOT the systemd maintainers) to have it ready and functioning. What's more, I believe that work is well advanced and you'll find more information about that in this thread. A little empathy for fellow developers, a little time looking in the mirror and some effort to see things from other perspectives would go a long way and be greatly appreciated. Stuart -- Stuart Prescotthttp://www.nanonanonano.net/ stu...@nanonanonano.net Debian Developer http://www.debian.org/ stu...@debian.org GPG fingerprint90E2 D2C1 AD14 6A1B 7EBB 891D BBC1 7EBB 1396 F2F7 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/lqogpu$i0r$1...@ger.gmane.org
Bug#758638: ITP: python-diff-match-patch -- robust algorithms for synchronizing plain text
Package: wnpp Severity: wishlist Owner: Stuart Prescott * Package name: python-diff-match-patch Version : 20121119 Upstream Author : Neil Fraser * URL : https://pypi.python.org/pypi/diff-match-patch * License : Apache-2.0 Programming Lang: Python 2 and 3 Description : robust algorithms for synchronizing plain text The Diff Match and Patch libraries offer robust algorithms to perform the operations required for synchronizing plain text. . * Diff: Compare two blocks of plain text and efficiently return a list of differences. * Match: Given a search string, find its best fuzzy match in a block of plain text. Weighted for both accuracy and location. * Patch: Apply a list of patches onto plain text. Use best-effort to apply patch even when the underlying text doesn't match. . This package provides the Python 2 version of the module. This package is a dependency of the latest release of the translate-toolkit (which has actually been including a private copy of this module for some time). -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140819140904.1513.39109.report...@jatayu.nanonanonano.net
Re: inconsistent versions of M-A: same packages
UDD can help with this. A list of source packages that have M-A: same binary packages in jessie that have different versions in any two release architectures is at: http://debian.nanonanonano.net/qa/maskew There are currently 247 source packages in that list (assuming I've not done something very silly in that SQL). The list is generated by a very brief script in: http://debian.nanonanonano.net/qa/macheck While I'm currently running that from cron on that box, this would be better run on udd.d.o or qa.d.o, dropping the output in a suitable place. It's quite feasible to extend that script to prepare a list of version→arch mappings for each source package. cheers Stuart -- Stuart Prescotthttp://www.nanonanonano.net/ stu...@nanonanonano.net Debian Developer http://www.debian.org/ stu...@debian.org GPG fingerprint90E2 D2C1 AD14 6A1B 7EBB 891D BBC1 7EBB 1396 F2F7 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/m3kab7$15v$1...@ger.gmane.org
Re: DEP-8 extension proposal: Add source package header
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Martin, The contents of all source packages is already available in Contents-source.gz on your favourite mirror [1]. That means you can: $ apt-file -a source update … $ apt-file -a source -l search debian/tests/control apipkg bobo bzr bzr-email bzr-fastimport bzr-git … $ apt-file -a source -l search debian/tests/control | wc -l 66 Maybe this is an easier option than adding yet another new field and patching tools to generate it. cheers Stuart [1] wheezy, sid, experimental (not older releases), http://cdn.debian.net/debian/dists/sid/main/Contents-source.gz - -- Stuart Prescott www.nanoNANOnano.net -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAk/Ye/oACgkQn+i4zXHF0ai1hQCguRLGOfvM1BrOKlhAcH8YsPtw ZmsAn0gjtAi1YRF03VyT/yYgBoxLbjvT =Hwvn -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/jr9u63$nju$1...@dough.gmane.org
Bug#709143: ITP: cssmin -- YUI CSS compression algorithm in Python
Package: wnpp Severity: wishlist Owner: Stuart Prescott * Package name: cssmin Version : 0.1.4 Upstream Author : Zachary Voase * URL : http://github.com/zacharyvoase/cssmin * License : Expat Programming Lang: Python Description : YUI CSS compression algorithm in Python cssmin is a Python port of the YUI Cascading Style Sheet (CSS) compressor. It can be used as a module from other Python programs, including as a filter for python-webassets bundles. It can also be used from the command line. cssmin is used by pootle (see #677319) as a webassets filter from version 2.5 onwards. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130521065445.15631.1667.report...@huma.nanonanonano.net
Re: systemd .service file conversion
> FWIW, I happen to agree with Marc. Having everything in /etc makes it > *much* clearer what the actual current configuration is; it also means > that if the defaults change on upgrade, your environment doesn't > suddenly start acting differently or inconsistently. If we want everything that makes a configuration decision in our /etc then we would want all the source packages there. After all, every tool we use has some sort default behaviour compiled into it. If desired, it can (often) be overridden with a config file in /etc (perhaps setting the environment appropriately). Open just about any man page and look for the word "default" and ask if, when we say "all configuration in /etc", do we actually have that? Is the configuration default that "ls --color" uses red for compressed files expressed in /etc? How about apt using priorities of 100 for installed packages and 500 for packages in repositories? Or grep(1) using basic regex not extended regex? Or find(1) not following symbolic links? Or that relatime is a default mount option for ext4? But do we care? No. We're able to distinguish between defaults and local configuration for all these standard tools. We understand that there are defaults and if we don't like them we need to create a configuration file or change our set-up in some way. We don't demand that apt install a /etc/apt/preferences that contains that default pinning, we accept that there is a default and we know that, if we want to override it, we should create that file ourselves and configure away. I idly wondered if perhaps /lib/udev just should be compiled into one (ugly) binary file so that it didn't *look* like a pile of text configuration files. Then, perhaps everyone would be happier as it would be easier to distinguish between "compiled in defaults" and local configuration. But even that isn't necessary -- we've already shown we can cope files that look like config files being in other locations to provide us with defaults -- xorg packages drop files with defaults in /usr/share/X11/xorg.conf.d/ that we can cheerfully override in /etc/X11/xorg.conf.d/ if we need to. The 1200 packages that ship files in foo.d/ directories that aren't inside /etc would tend to suggest we can cope with this. I think policy is quite clear -- configuration files live in /etc. This part of policy is designed to stop (for example) some silly web app having us hunt around to find /usr/share/foo/config.php instead of permitting us to configure the thing from /etc. It is not trying to conflate defaults with configuration files; I think we're good at misidentifying which files are configuration files. So in all these other cases including traditional unix tools and our own tools that we use on a daily basis, we manage to have defaults *not* in /etc and the local configuration files that change the defaults in /etc. I am left wondering why udev supposed to be different to that. -- Stuart Prescotthttp://www.nanonanonano.net/ stu...@nanonanonano.net Debian Developer http://www.debian.org/ stu...@debian.org GPG fingerprintBE65 FD1E F4EA 08F3 23D4 3C6D 9FE8 B8CD 71C5 D1A8 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/kofjml$3np$1...@ger.gmane.org
Re: [PROPOSAL v2] Orphaning another maintainer's packages
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 > I think four weeks would be much better. A maintainer might > reasonably go abroad for 2-3 weeks - we even have a VAC process for > handling absences. (And we don't want to complicate this third-party > orphan process with references to VACs.) Remember that we do not really have a VAC process for the ~50% of maintainers who are not DDs [1]. That group of maintainers have no real way of letting the rest of the project know that they are on VAC [2]. They also have an interest in and a proven ability to maintain packages and so may like to help out with other unmaintained packages ... after all, we they are encouraged time and time again to adopt packages rather than introduce new ones into the archive. But they cannot know if the maintainer is on VAC or not to engage in this process. I'm not suggesting that VAC status should be public information, but blanket statements that we know if maintainers are on VAC (or MIA or whatever) are wrong for 50% of our maintainers as are statements that potential salvagers have this information. cheers Stuart [1] http://lists.debian.org/jr6344$lkp$1...@dough.gmane.org [2] I would encourage them to let their sponsors know this since the sponsors are in the position of helping care for their packages anyway - -- Stuart Prescotthttp://www.nanonanonano.net/ stu...@nanonanonano.net Debian Developer http://www.debian.org/ stu...@debian.org GPG fingerprintBE65 FD1E F4EA 08F3 23D4 3C6D 9FE8 B8CD 71C5 D1A8 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iEYEARECAAYFAlCP7EgACgkQn+i4zXHF0ajEqACgvyXY9SvtOYjjh0RsaUrgO580 n7UAoNPA7ggz/QbjhHBaO4K3ZPdqsiXi =5Qyy -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/k6oq8f$22k$1...@ger.gmane.org
Re: Multiple source package entries in Sources file
>> So whats the point in having multiple versions of the same source >> package? > > My guess: there are multiple versions of the binary packages depending > on the architecture, and the archive kept the corresponding source > packages. Indeed -- gcc-snapshot has a habit of failing to build on some architectures so it's not that there are lots of different versions in the Sources (or Packages) for any one port. Either talking to UDD directly or using rmadison can tell us more about this: udd=> select version, architecture from packages where source = 'gcc- snapshot' order by version; version| architecture ---+ 20120313-1| ia64 20120407-1+b1 | hurd-i386 20120704-1| kfreebsd-amd64 20121008-1| armel 20121106-1| sparc 20121120-1| armhf 20121120-1| amd64 20121120-1| mips 20121120-1| mipsel 20121120-1| powerpc 20121120-1| s390 20121120-1| s390x 20121120-1| i386 (13 rows) The buildd status [1] shows recent builds and build failures. Clicking on "ia64" will show you that the last successful build of gcc-snapshot was the 20120313 version, which is why it's still there in the ia64 port. [1] https://buildd.debian.org/status/package.php?p=gcc-snapshot&suite=sid -- Stuart Prescotthttp://www.nanonanonano.net/ stu...@nanonanonano.net Debian Developer http://www.debian.org/ stu...@debian.org GPG fingerprintBE65 FD1E F4EA 08F3 23D4 3C6D 9FE8 B8CD 71C5 D1A8 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/kaq2g8$ois$1...@ger.gmane.org
Bug#696833: ITP: i18nspector -- checking tool for gettext POT, PO and MO files
Package: wnpp Severity: wishlist Owner: Stuart Prescott * Package name: i18nspector Version : 0.6 Upstream Author : Jakub Wilk * URL : http://jwilk.net/software/i18nspector * License : Expat Programming Lang: python Description : checking tool for gettext POT, PO and MO files i18nspector is a tool for checking translation templates (POT), message catalogues (PO) and compiled message catalogues (MO) files for common problems. These files are used by the GNU gettext translation functions and tools in many different development environments. Checks include: incorrect or inconsistent character encoding, missing headers, incorrect language codes and improper plural forms. This tool was formerly known as gettext-inspector. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20121227234534.18579.29079.report...@huma.nanonanonano.net
Bug#705452: docbook-xml: Fail to upgrade due to pre-depend problem
Helmut Grohne wrote: > > Stuart Prescott also tried demoting this Pre-Dependency to Depends and > > showed that the very same upgrade failure occurs. So this is not an > > option. > > The conclusion here is that the only way to fix this bug in sgml-base is > to have *no* dependency on dpkg at all. Actually, removing the dependency on dpkg doesn't change the outcome at all -- dpkg is already unpacked and configured in the debug output we have. (I also edited Packages to remove the sgml-base→dpkg relationship and verified it still fails in the same way). Andreas Beckmann wrote: > > Stuart Prescott also determined that kdepim + kde-plasma-desktop are > > enough to reproduce this problem. > > I could reproduce the problem in piuparts with installing/upgrading these two > packages, but it required --install-recommends. So there may be even a > smaller set of packages needed to reproduce the problem by cutting out some > recommended packages. I don't doubt that there is a smaller subset of packages that can reproduce this failure, especially since installing those two drags in several hundred others -- that was just as far as I had managed to get in narrowing it down (sufficient vs necessary). Yes, the vm in which I have been testing this on is a minimal installation + standard task and I've not touched defaults such as installing recommends. Some further testing narrows it down further to: # apt-get --no-install-recommends install kde-window-manager # sed -i s/squeeze/wheezy/ /etc/apt/sources.list; apt-get update; apt-get -s - o Debug::pkgPackageManager=true dist-upgrade → FAIL with error we have seen # dpkg -r kde-window-manager # apt-get -s -o Debug::pkgPackageManager=true dist-upgrade → PASS # dpkg -i /var/cache/apt/archives/kde-window-manager*deb # apt-get -s -o Debug::pkgPackageManager=true dist-upgrade → FAIL with error we have seen kde-window-manager has a dependency on perl which is involved in the failure here, but it's not obvious to me why this is happening (and kde-window-manager still drags in about 200 packages so we've still got a large problem space to look at). cheers Stuart -- Stuart Prescotthttp://www.nanonanonano.net/ stu...@nanonanonano.net Debian Developer http://www.debian.org/ stu...@debian.org GPG fingerprintBE65 FD1E F4EA 08F3 23D4 3C6D 9FE8 B8CD 71C5 D1A8 GPG fingerprint90E2 D2C1 AD14 6A1B 7EBB 891D BBC1 7EBB 1396 F2F7 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201304181458.23106.stu...@debian.org
Re: Bits from the autopkgtest maintainer
Antonio Terceiro wrote: > On Mon, Mar 03, 2014 at 11:22:23PM +0100, Jakub Wilk wrote: >> * Martin Pitt , 2014-02-27, 17:38: >> >Tests can now depend on "@builddeps@" which expands to the source >> >package's build dependencies. This is useful if you have many >> >build dependencies which are only necessary for running the test >> >suite and you don't want to replicate them in the test Depends:. >> >> I advise to never use @builddeps@. It's a great way to shoot >> yourself in the foot. :\ > > would you ellaborate? I would consider it to be a poor test of the built package if packages that were not in Recommends, Suggests or packages specifically needed as a test runner (e.g. python-nose) were being installed. Installing packages other than those ones means that whether the Depends/Recommends/Suggests are complete is not being tested [1]. This is a class of bug that keeps coming up and one of the reasons why autopkgtest tests are so attractive. There is of course another class of tests where correct operation is ensured while other non-required packages are installed (e.g. an alternative implementation etc) but that still isn't build-deps. (I don't know if that's what Jakub had in mind, but that's my 2¢) cheers Stuart [1] Where possible, separate tests for Depends, Depends+Recommends, Depends+Recommends+Suggests would seem even better to test the graceful failure (or otherwise) in the absence of these related packages. -- Stuart Prescotthttp://www.nanonanonano.net/ stu...@nanonanonano.net Debian Developer http://www.debian.org/ stu...@debian.org GPG fingerprint90E2 D2C1 AD14 6A1B 7EBB 891D BBC1 7EBB 1396 F2F7 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/lf6ge0$v4h$1...@ger.gmane.org
Re: packaging of MATLAB files
Sébastien Villemot wrote: > Le samedi 08 mars 2014 à 12:18 +, Ghislain Vaillant a écrit : >> I am currently working on packaging a scientific project for which >> MATLAB wrappers are available. I was wondering where these should be >> installed in the file system tree and whether there were particular >> things to be careful with. I am talking about pure MATLAB files for >> now, i.e. only files with .m extension, no mex files. > > The first thing to figure out is whether your .m files run under GNU > Octave (which is likely, but needs to be verified). If not, the .m files > cannot be put in the main section of Debian since they depend on nonfree > software, and should rather go in the contrib section. I would disagree with this interpretation. We have lots of things in the archive that are designed to interoperate with non-free software. - packages provide files in /usr/share/doc/$package/examples that require things not in Debian - packages provide interfaces to read files that might not be able to be generated by anything in Debian - we include software that interfaces with non-free services Now if matlab were required for operation of this package, then it's heading towards contrib rather than main. But just because the .m files are not useful to people without matlab, they are useful as examples to people who do have matlab and there's no reason to deprive those users of useful files. We shouldn't pretend that the examples are universally useful though and a README to that effect would be appropriate. Of course if they just worked with octave, then that would be even better. cheers Stuart -- Stuart Prescotthttp://www.nanonanonano.net/ stu...@nanonanonano.net Debian Developer http://www.debian.org/ stu...@debian.org GPG fingerprint90E2 D2C1 AD14 6A1B 7EBB 891D BBC1 7EBB 1396 F2F7 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/lfkbvc$41v$1...@ger.gmane.org
Re: ':any' syntax in package names in jessie/sid Packages
Hi Eugene, > It seems that in jessie (and similar in sid) a number of packages [1] > started to use ':' symbol in their dependency lists as part of package > names. This is, if I'm not misreading the Debian Policy §7.1 and §5.6.1, > is not allowed. > > Suggestions for issue's severity and how to proceed? I think you've found yet another "multiarch is not documented in policy" bug. This specific issue is not yet filed, so perhaps filing a bug to track this problem would be appropriate. #687900: document multiarch #650974: Make Policy references to /usr/lib multiarch-aware #684672: document multiarch tuple definitions #742756: multi-arch and system-dependent header files #636383: 10.2 and others: private libraries may also be multi-arch-ified #621050: Document dependencies needed to use multiarch paths Unfortunately, the people who understand multiarch well enough to write it up for policy haven't done so which leaves us with no normative documentation in policy for the the Multi-Arch field in Packages, no description of how the package manager should deal with multi-arch packages and their dependencies and no documentation of best practices for -dev packages etc. As with the rest of multiarch, the documentation of python:any is at: https://wiki.ubuntu.com/MultiarchSpec#Extended_semantics_of_per- architecture_package_relationships (I believe that there are some aspects of that document that have not been implemented in Debian or have been implemented differently in Debian -- it's not a substitute for having this in Policy) Hope that helps Stuart -- Stuart Prescotthttp://www.nanonanonano.net/ stu...@nanonanonano.net Debian Developer http://www.debian.org/ stu...@debian.org GPG fingerprint90E2 D2C1 AD14 6A1B 7EBB 891D BBC1 7EBB 1396 F2F7 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/liqk21$5nc$1...@ger.gmane.org
Re: ':any' syntax in package names in jessie/sid Packages
Thorsten Glaser wrote: > Stuart Prescott debian.org> writes: > >> Unfortunately, the people who understand multiarch well enough to write >> it up for policy haven't done so which leaves us with no normative >> documentation in policy for the the Multi-Arch field in Packages, no >> description of how the package manager should deal with multi-arch >> packages and their dependencies and no documentation of best practices >> for -dev packages etc. > > This can be read as "M-A in its current form is RC-buggy and must > not be released". With the obvious follow-ups (revert M-A perl/python > in sid, as Guillem said). I'd rather that we just sorted out some real documentation for it and then fixed the bugs in our tools that we have due to things like :any appearing. Stuart -- Stuart Prescotthttp://www.nanonanonano.net/ stu...@nanonanonano.net Debian Developer http://www.debian.org/ stu...@debian.org GPG fingerprint90E2 D2C1 AD14 6A1B 7EBB 891D BBC1 7EBB 1396 F2F7 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/lj0lgj$fu4$1...@ger.gmane.org
Re: ':any' syntax in package names in jessie/sid Packages
> As xnox says there is still some pending changes around the interpreter
> problem, as described here:
> https://wiki.debian.org/HelmutGrohne/MultiarchSpecChanges
>
> And that debate is part of the reason this stuff hasn't been
> considered 'finalised' and thus ready for policy. But I think the core
> stuff is now well-enough used that at the very least policy should not
> be inconsistent with it.
pending changes, things still to be finalised, undocumented syntax changes
being pushed into jessie that broke wheezy→jessie upgrades (which had to be
fixed in both dh_python{2,3} and also required a stable update to apt
[1])... this worries me. It feels like it is being done backwards.
This is the exact situation where I would like to see policy lead the way
and be part of the process to design and codify things *before* we start
implementing them on 21k packages. This is a general comment, not just about
multi-arch -- our policy editors have a huge amount of experience in
developing technical policies and documentation to go with them. Making use
of their expertise at the design stage would be much better for the project.
Currently, the project seems to tend towards policy documenting current
practice rather than policy leading us towards better (best!) practice; this
culture means that improving things can be very hard because you may have to
become policy non-compliant in order to develop the new "standard practice"
to then seek a change in policy. (And as observed recently, this also means
that when given a choice between A and B, we end up choosing A, B, C and Z
[2].)
cheers
Stuart
[1] #723586
[2] http://lists.debian.org/87y4zc3jix.fsf%40windlord.stanford.edu
--
Stuart Prescotthttp://www.nanonanonano.net/ stu...@nanonanonano.net
Debian Developer http://www.debian.org/ stu...@debian.org
GPG fingerprint90E2 D2C1 AD14 6A1B 7EBB 891D BBC1 7EBB 1396 F2F7
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/lj0naf$7v7$1...@ger.gmane.org
Re: Age of built packages to be part of the jessie release?
Svante Signell wrote: > I wonder how old a package build can be to be part of the release. Some > packages are built up to a year ago, and rebuilding them now FTBFS. As others have noted already, there are period archive rebuilds to check what would now ftbfs. Slightly orthogonal to your question, "up to a year ago" doesn't come close, actually... 42% of source packages in jessie were uploaded over a year ago, 25% over two years ago, 15% over three years ago, 9% over four years ago. Fun fact: there are 64 source packages in jessie that are over 10 years old. Age of source packages in each release: http://ircbots.debian.net/stats/package_ages.png (note: this is based on source package uploads; binNMUs not included) -- Stuart Prescotthttp://www.nanonanonano.net/ stu...@nanonanonano.net Debian Developer http://www.debian.org/ stu...@debian.org GPG fingerprint90E2 D2C1 AD14 6A1B 7EBB 891D BBC1 7EBB 1396 F2F7 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/m4sqt2$kk3$1...@ger.gmane.org
Re: debian github organization ?
Jonathan Dowland wrote: > Some people and teams in Debian do manage their package sources in git; > others don't. I'm not sure what the stats are at the moment for the > various approaches; there might be a UDD script already that generates > some. I was interested in looking at this, once upon a time. There is indeed a regular check of VCS usage: http://upsilon.cc/~zack/stuff/vcs-usage/ Which today lists: arch7 bzr 199 cvs 11 darcs 832 git 12439 hg 65 mtn 23 svn 3593 Source packages using some VCS: 17169 (75.37%) So that puts git as the declared VCS for > 50% source packages (and leading the next most popular by almost a factor of 4). -- Stuart Prescotthttp://www.nanonanonano.net/ stu...@nanonanonano.net Debian Developer http://www.debian.org/ stu...@debian.org GPG fingerprint90E2 D2C1 AD14 6A1B 7EBB 891D BBC1 7EBB 1396 F2F7 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/mgso52$2rc$1...@ger.gmane.org
Re: How continious is debci?
Hi Ole, I see that fitscut doesn't declare that it has a test suite in d/control. While dpkg adds that field into the dsc file for you [1], I don't now how that interacts debci which states that the maintainer needs to add that field to debian/control [2]. I don't know whether debci looks in d/control or in the dsc (or in Sources) to find packages to test. [1] http://sources.debian.net/src/dpkg/1.17.25/ChangeLog/#L6457 [2] http://anonscm.debian.org/cgit/collab-maint/debci.git/tree/README.md#n15 cheers Stuart -- Stuart Prescotthttp://www.nanonanonano.net/ stu...@nanonanonano.net Debian Developer http://www.debian.org/ stu...@debian.org GPG fingerprint90E2 D2C1 AD14 6A1B 7EBB 891D BBC1 7EBB 1396 F2F7 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/mj8qtq$o85$1...@ger.gmane.org
Re: Introducting Debian Trends: historical graphs about Debian packaging practices, and "packages smells"
Hi Andreas > My point is simply: As long as the released lintian does not find the > said issue - how can I file a sensible bug report the lintian authors > will consider an issue? I totally welcome if you would file a more > qualified bug report with the insight you have proven in this thread to > make lintian authors understand the problem. The released lintian does report the same details $ lintian -L =classification prottest_3.4.2+dfsg-3.dsc C: prottest source: rules-requires-root-implicitly C: prottest source: debian-build-system debhelper C: prottest source: source-format 3.0 (quilt) $ lintian --version Lintian v2.12.0~bpo9+1 FYI for prottest, you could set the locale detail LC_ALL=C.UTF-8 for the entire debian/rules rather than only for the dh call. Stuart -- Stuart Prescotthttp://www.nanonanonano.net/ stu...@nanonanonano.net Debian Developer http://www.debian.org/ stu...@debian.org GPG fingerprint90E2 D2C1 AD14 6A1B 7EBB 891D BBC1 7EBB 1396 F2F7
Re: Re: Updating dpkg-buildflags to enable reproducible=+fixfilepath by default
Sune Stolborg Vuorela wrote: > Can you provide some kind of hook in the environment so we at least can work > around it in the users, so that the internal functions (where the output of > __FILE__ is forwarded to) can glue e.g. the content of an environment > variable in front of the usage of the __FILE__ content to try to > reconstruct it at runtime, so that all packages doesn't need to do export > SOURCE_BASE_DIR=`pwd`; make test, but it will just work if we patch Qt and > similar libraries ? +1 for the request for the build system to provide for a reference point for where the source is to be found. SOURCE_BASE_DIR has a delightful symmetry to SOURCE_DATE_EPOCH and the algorithm for use is similar: if it is in the environment then use it, if not, fall back to the previous behaviour. At its crudest level, a package's debian/rules could include SOURCE_BASE_DIR= $(shell pwd); however, putting this into the build environment saves source changes in multiple packages, sets us up for future use across the entire ecosystem, signals to upstreams that this is a broad standard and not a mere hack in d/rules, and also saves maintainers from thinking about nasty corner cases to do with current directories with makefile invocation. Looking to the future, tests using SOURCE_BASE_DIR to locate test data would allow build-time tests to be repurposed as autopkgtest tests too, as the autopkgtest could tell the tests where the test input data is to be found. This would be a substantial improvement on the current situation where the tests can only be run at build time and not on ci.debian.net. By dpkg making SOURCE_BASE_DIR 'real', there is a distinct prospect of Debian carrying Qt5 patches to use it (thanks Sune!) and for Qt6 to include them upstream. regards Stuart -- Stuart Prescotthttp://www.nanonanonano.net/ stu...@nanonanonano.net Debian Developer http://www.debian.org/ stu...@debian.org GPG fingerprint90E2 D2C1 AD14 6A1B 7EBB 891D BBC1 7EBB 1396 F2F7
Re: Is distro-tracker accessible by some sort of API?
Hi Roberto
> does source package 'foo' exist in release 'bar'?
>
> Looking at the UDD wiki page and the associated examples, it seems like
> the query I need is something roughly like:
>
> SELECT COUNT(*) FROM public.packages WHERE source='foo' AND release='bar';
>
> Is this the best approach?
FWIW there are python bindings and CLI tools for UDD floating around ... I
really should package them (and having people interested in them would be
good motivation for that)
$ ipython3
In [1]: import uddcache.udd
In [2]: udd = uddcache.udd.Udd()
In [3]: pkg = udd.BindPackage('libc6', arch='amd64', release='bullseye')
In [4]: pkg.IsAvailable()
Out[4]: True
In [5]: pkg = udd.BindPackage('no-such-package', arch='amd64',
release='bullseye')
In [6]: pkg.IsAvailable()
Out[6]: False
$ udd-cache versions libc6
Package: libc6 None/amd64
squeeze: 2.11.3-4
wheezy:2.13-38+deb7u10
wheezy-security: 2.13-38+deb7u12
jessie:2.19-18+deb8u10
jessie-security: 2.19-18+deb8u10
stretch-security: 2.24-11+deb9u1
stretch: 2.24-11+deb9u4
buster:2.28-10
bullseye: 2.29-7
sid: 2.29-9
experimental: 2.30-0experimental1
$ udd-cache versions libc6 --release bullseye
Package: libc6 bullseye/amd64
bullseye: 2.29-7
$ udd-cache versions no-such-package --release bullseye
No package named 'no-such-package' was found in bullseye/amd64.
cheers
Stuart
--
Stuart Prescotthttp://www.nanonanonano.net/ stu...@nanonanonano.net
Debian Developer http://www.debian.org/ stu...@debian.org
GPG fingerprint90E2 D2C1 AD14 6A1B 7EBB 891D BBC1 7EBB 1396 F2F7
Re: no-strong-digests-in-dsc MBF
Hi Adrian, > I want to do a MBF for all packages without a SHA256 checksum field > in the .dsc [1] - only SHA1 as hash would not be good in stretch. I missed two details here: * why is this worth going at all * why is this important enough for the bugs to be release-critical (which means, after all: either drop the package or delay the release). The hashes inside the .dsc file are not used in Debian once the package has been accepted by dak. * The trustable way of getting the source package is with apt-get source, when apt verifies the Release signature → hashes → Sources → hashes for each part of the source package: dsc, orig.tar.gz, diff.gz/diff.tar.xz * The not-really-trustable way of getting the source package is with "dget http://.../package.dsc";. Using the dsc directly, dget will check the signature on the dsc and check the hashes. However, the signature can be from a weak key, an expired key, a key you've never heard of (sponsored upload) or a key from a ex-DD that is no longer in the keyring. Basically, there are so many ways that signature verification on the dsc can go wrong that it's not useful except for packages that have only just been uploaded. If you can't trust the .dsc because you can't check its signature, then there's little point in worrying about weak vs strong hashes inside the .dsc. Given the hashes aren't used within Debian and can't be used reliably by external parties either, it doesn't feel like a good use of anyone's time. (I agree with you that this test is potentially a good way of finding MIA maintainers and undermaintained packages -- just reuploading packages to get stronger hashes and doing nothing to actually improve the package actually works against this goal. It will remove the package from this list and makie it look like the the package has been uploaded with some maintenance, while changing nothing.) cheers Stuart -- Stuart Prescotthttp://www.nanonanonano.net/ stu...@nanonanonano.net Debian Developer http://www.debian.org/ stu...@debian.org GPG fingerprint90E2 D2C1 AD14 6A1B 7EBB 891D BBC1 7EBB 1396 F2F7
Re: no-strong-digests-in-dsc MBF
Hi Matthias, On Wed, 18 Jan 2017 00:31:44 Matthias Klumpp wrote: > > The hashes inside the .dsc file are not used in Debian once the package > > has > > been accepted by dak. > > I do require them in Debian derivatives (Tanglu / PureOS) and .dsc > files without the up-to-date signatures are quite a pain to handle. Remaking the hashes in the dscs on a few packages isn't going to fix the much wider signature problem, unfortunately. You're always going to have an exciting selection of signatures on both old and new packages that are hard to work with for the reasons already enumerated. Without knowing your workflow for importing packages, does not the Sources index provide better and most importantly, signed information? > > * The trustable way of getting the source package is with apt-get source, > > when apt verifies the Release signature → hashes → Sources → hashes for > > each part of the source package: dsc, orig.tar.gz, diff.gz/diff.tar.xz > > If you mirror Debian's archive into dak again, this becomes a problem, > since dak (for good reason) will not import packages with weak > checksums, so re-importing source packages is a challenge. Ahh... and I take it that's not configurable in dak. So reuploading the packages would solve half the problem (hashes) but not the other half (signatures). cheers Stuart -- Stuart Prescotthttp://www.nanonanonano.net/ stu...@nanonanonano.net Debian Developer http://www.debian.org/ stu...@debian.org GPG fingerprint90E2 D2C1 AD14 6A1B 7EBB 891D BBC1 7EBB 1396 F2F7
Re: CUPS GPL → Apache license change, how to proceed?
Didier 'OdyX' Raboud wrote: > - What tools should I be using to identify which of these will be > undistributable constructs? Aka: how, given a list of source packages, > can I determine which are GPL-2-only in the codepaths that link against > CUPS? > [CUPS-links-to] CUPS dynamically links against > (excluding 'system libraries' such as libc, libgcc, libstdc++) > - cups → libusb-1.0-0 (LGPL-2.1) > - libcups2 → libavahi-client3 & libavahi-common3 (GPL-2+) > - libcups2 → libc6 (GPL-2+) > - libcups2 → libgnutls30 (LGPL-2.1+) > - libcups2 → libgssapi-krb5-2 (MIT) > - libcups2 → zlib1g (Zlib) Having looked at python-debian's debian.copyright.Copyright module just the other day, I thought there might be something that could be done here. With 77% of the packages in the rdeps list that have a readable copyright- format/1.0 (or an older format), we can make reasonable progress. * we can say that 3746 (70%) of the packages in the build-rdeps list have no *direct* problem because they are not GPLv2-only. (That is to ignore that they might depend on packages that are themselves in trouble with this licence change) * there are 379 packages that are GPLv2-only; that doesn't mean that they definitely load both GPLv2-only code and libcups* into the same executable, but they need checking. (gplv2-only.txt attached) * 1220 packages haven't been checked; most aren't in copyright-format/1.0 but a few generate parse errors or have sufficiently complicated licence terms that this tool can't figure it out. (unknown.txt attached) These good(ish) looking numbers at least cut down the scope of the checking that is required by 70%. There's still 1600ish packages that need to be looked at in some way. I'm not sure what the next steps would be. Perhaps walking the dependency tree looking at these 1600 packages is what should happen next. We would likely find places where the tree can be pruned because there is no linking involved, merely use of a tool at build time. I'm sure we've got graph walking code in the archive somewhere that might help… For those in need of amusement, code at https://salsa.debian.org/stuart/package-license-checker and all relevant copyright files (current as of unstable today) from the packages analysed at https://people.debian.org/~stuart/copyright.tar.xz Happy for suggestions, merge requests etc! cheers Stuart -- Stuart Prescotthttp://www.nanonanonano.net/ stu...@nanonanonano.net Debian Developer http://www.debian.org/ stu...@debian.org GPG fingerprint90E2 D2C1 AD14 6A1B 7EBB 891D BBC1 7EBB 1396 F2F7389-admin-console 389-ds-console 4pane abiword aeskulap airport-utils akonadi akonadi-contacts akonadiconsole alsa-tools alt-ergo android-framework-23 android-platform-libcore apophenia ask asterisk asunder audacity baloo bibtex2html bindex blender blktrace blogilo calf calibre calligra cdbs ceph cl-asdf comedilib cpl cups-filters daisy-player dar denemo dia diffoscope djvusmooth doc-linux-fr dogtag-pki dolphin-emu doxygen dozzaqueux dpdk dpmb dpuser drupal7 dtd-parser dune-common dune-geometry dune-grid dune-istl dune-localfunctions edb-debugger edfbrowser eiskaltdcpp espresso evas-loaders exactimage fbpanel felix-framework felix-main felix-osgi-obr ferret-vis fio foomatic-db foxtrotgps frama-c free42-nologo freefem++ freemat frei0r gajim gamera gazebo geany-plugins geg geneweb getdp gfarm gigedit git-cola gkrellm-gkrellmpc gkrellm2-cpufreq gkrelluim gmanedit gmidimonitor gmrun gmsh gmtp gnome-colors gnuais goobox goocanvas-2.0 goocanvasmm-2.0 gpicview gpsprune gpsshogi gpt grace grantlee5 grass groovy gspiceui gtk-sharp3 gtk2-engines-xfce gxmms2 hardinfo haskell-yi-frontend-pango heaptrack hedgewars hhvm highlight.js iio-sensor-proxy ikiwiki imview ini4j instead invesalius isomaster istack-commons jack-mixer jalview java-imaging-utilities java3d javamail jaxb jaxb-api jaxrs-api jd jenkins-htmlunit-core-js jericho-html jersey1 jmol josm jsjac jtharness jtreg juffed kaccounts-integration kajongg kalarm kamailio kcachegrind kdbg kde-dev-scripts kdeconnect kdelibs4support kdepim-addons kdepim-runtime kdepimlibs kdocker keepassx kf5-messagelib kio kio-extras kjots kleopatra kmail kmailtransport kmenuedit kodi korganizer kpimtextedit krita ksirk kstars ksyntax-highlighting ksysguard ktexteditor kturtle ladish lammps latex2html latexdiff ldm ldm-themes libaopalliance-java libemf libexif-gtk libgaminggear libhtmlcleaner-java libitext1-java libj2ssh-java libjgroups-java libjpfcodegen-java libjsr166y-java libjtds-java libkf5calendarsupport libkf5eventviews libkf5grantleetheme libkf5gravatar libkf5incidenceeditor libkf5ksieve libkf5libkdepim libkf5libkleo libkf5mailcommon libkf5mailimporter libkf5pimcommon libnb-javaparser-java libodb-qt libpulse-java librecad libreoffice libsimple-validation-java libswarmcache-java libzypp light-locker lightdm lightdm-gt
Re: Debian Policy 4.1.4.0 released
Hi Andreas
>> > 4.9
>> > The ``get-orig-source`` rules target has been removed. Packages
>> > should use ``debian/watch`` and uscan instead.
>>
>> Especially for this, my ‘debian/rules’ files thank you.
>
> While I really like to have this consistent approach but it seems I've
> missed how uscan can spot new versions in for instance untagged VCS or
> download files with changing content but no version number. Is there
> some way to do this with something else than a manually craftet script?
yes, d/watch can use the qa.debian.org fakeupstream service to create a fake
new release for every
commit. I use this on projects that have very occasional (bugfix-only) commits
and don't seem to be
interested in actually making releases any more:
https://sources.debian.org/src/svn-all-fast-export/1.0.10+git20160822-3/debian/watch/
opts="uversionmangle=s/.*date=(\d{4})-(\d\d)-(\d\d)T.*/1.0.10+git$1$2$3/, \
filenamemangle=s/.*date=(\d{4})-(\d\d)-(\d\d)T.*/1.0.10+git$1$2$3.tar.gz/" \
https://qa.debian.org/cgi-bin/fakeupstream.cgi?upstream=github_commits_package_json/svn-all-fast-export/svn2git
\
.*/archive/(.*\.tar\.gz?.*)
A version 1.0.10+git20180406 would therefore appear from a commit made
yesterday and if I were to package
and upload that version, that would also be the upstream part of the version
string I'd use. With uscan
integration, tools like the UDD Maintainer Dashboard also show when new commits
are made.
(Thanks to Paul Wise for creating this a couple of years ago when I was musing
on how to track this sort
of upstream)
cheers
Stuart
--
Stuart Prescotthttp://www.nanonanonano.net/ stu...@nanonanonano.net
Debian Developer http://www.debian.org/ stu...@debian.org
GPG fingerprint90E2 D2C1 AD14 6A1B 7EBB 891D BBC1 7EBB 1396 F2F7
Re: Please do not drop Python 2 modules
Ian Jackson wrote:
> Can lintian tell whether there is a Python 3 module too ? If so then
> I think a better criterion for warning would be "there is no Python 3
> module".
$ lintian-info -t python-foo-but-no-python3-foo
W: python-foo-but-no-python3-foo
N:
N: This source package appears to generate the specified Python 2 package
N: without creating a variant for Python 3.
N:
N: The 2.x series of Python is due for deprecation and will not be
N: maintained past 2020.
N:
N: If upstream have not moved or have no intention to move to Python 3,
N: please be certain that Debian would benefit from the continued
N: inclusion of this package and, if not, consider removing it.
N:
N: Alternatively, ensure that the corresponding package specifies the
N: ${python3:Depends} substvar in its binary dependencies.
N:
N: Severity: normal, Certainty: certain
N:
N: Check: python, Type: source, binary
N:
--
Stuart Prescotthttp://www.nanonanonano.net/ stu...@nanonanonano.net
Debian Developer http://www.debian.org/ stu...@debian.org
GPG fingerprint90E2 D2C1 AD14 6A1B 7EBB 891D BBC1 7EBB 1396 F2F7
Re: make compilation not so gray
Ben Caradoc-Davies wrote: > Exhibit A: dpkg-buildpackage (attached). This was just the one in front > of me. FWIW if I have chosen to configure a terminal with a light coloured background, I also configure the standard ANSI colours so that there will be sufficient contrast to read them against my chosen background. That usually means increasing saturation and decreasing lightness for the colours. The dpkg-source warning you showed appears as a brownish colour and is perfectly legible for me. cheers Stuart -- Stuart Prescotthttp://www.nanonanonano.net/ stu...@nanonanonano.net Debian Developer http://www.debian.org/ stu...@debian.org GPG fingerprint90E2 D2C1 AD14 6A1B 7EBB 891D BBC1 7EBB 1396 F2F7
Re: sarge bo rex
> What is the sequence of Debian release names? In addition to the other answers, machine readable data are in the package distro-info-data: /usr/share/distro-info/debian.csv See "apt-cache rdepends distro-info-data" for shell, python and perl bindings. Stuart -- Stuart Prescotthttp://www.nanonanonano.net/ stu...@nanonanonano.net Debian Developer http://www.debian.org/ stu...@debian.org GPG fingerprint90E2 D2C1 AD14 6A1B 7EBB 891D BBC1 7EBB 1396 F2F7
Re: intended MBF: wrong redirections in maintainer scripts
Adam Borowski wrote: > On Tue, Aug 07, 2018 at 12:38:32PM +0200, Wouter Verhelst wrote: >> On Sat, Aug 04, 2018 at 01:15:57PM +0800, Ralf Treinen wrote: >> > as announced in our talk at debconf'18 [1] we intend a MBF about wrong >> > redirections in maintainer scripts. In general these are of the form >> > >> > foo 2>&1 1> /dev/null >> > >> > Here it was probably intended to send both stderr and stdout to >> > /dev/null. >> >> What makes you say that? ;-) >> >> It may be that the maintainer did indeed want stdout to be discarded, >> but stderr not; for instance because they wanted to parse the stderr >> output. >> >> (not saying this is the most likely case, but you might want to >> double-check that before filing the bugs) > > Oy vey... I didn't notice this when Ralf's mail was posted (merely > checked whether I'm or QA are on the dd-list). But, indeed, this whole > MBF is wrong. Thanks Wouter! Not wrong, just having the potential for false positives. A cursory inspection using codesearch showed me 43 examples that where the redirections are wrong and only 1 example where the script was actually trying to capture stderr. (The code used by Ralf to find these picks up many more examples than my simple grep will pick up.) It may also be that Ralf and his team are already filtering out places where the output is captured; the talk by Ralf and Nicholas at DebConf is well worth watching. https://debconf18.debconf.org/talks/90-mining-debian-maintainer-scripts/ Not restricting the search to maintainer scripts finds many many more... it's a common enough mistake. regards Stuart -- Stuart Prescotthttp://www.nanonanonano.net/ stu...@nanonanonano.net Debian Developer http://www.debian.org/ stu...@debian.org GPG fingerprint90E2 D2C1 AD14 6A1B 7EBB 891D BBC1 7EBB 1396 F2F7
Re: Updating the policy for conflicting binaries names ? [was: Re: Re: New package netgen-lvs with binary /usr/bin/netgen - already taken]
Jonathan Dowland wrote: > Yes. Is "environment-modules" well-known these days? I'm surprised not > to see it mentioned more often. Indeed, environment-modules and direnv and excellent tools for this sort of game. -- Stuart Prescotthttp://www.nanonanonano.net/ stu...@nanonanonano.net Debian Developer http://www.debian.org/ stu...@debian.org GPG fingerprint90E2 D2C1 AD14 6A1B 7EBB 891D BBC1 7EBB 1396 F2F7
Bug#910484: ITP: python-backports.csv -- Backport of the Python 3 CSV module for Python 2
Package: wnpp Severity: wishlist Owner: Stuart Prescott * Package name: python-backports.csv Version : 1.0.6 Upstream Author : Python Software Foundation * URL : https://github.com/ryanhiebert/backports.csv * License : Python Software Foundation License v 2 Programming Lang: Python Description : Backport of the Python 3 CSV module for Python 2 This package contains a backport of the Python 3 stdlib module 'csv' bringing new features to Python 2. Packaging this module makes it easier to write code that works with both Python 2 and Python 3, also permitting upstreams to take advantage of the new features in the CSV module. python-backports.csv is a dependency of the current translate-toolkit release (2.3.1). python-backports.csv will presumably be part of buster but not bullseye.
Bug#859199: ITP: dh-curl-sudo-bash -- debhelper tools for automated non-packaging
Package: wnpp Severity: wishlist Owner: Stuart Prescott * Package name: dh-curl-sudo-bash Version : 1.1 Upstream Author : Lars Wirzenius and Stuart Prescott * URL : http://deb.li/U67E * License : BSD 3 clause Programming Lang: POSIX shell, Perl Description : debhelper tools for automated non-packaging The dh-curl-sudo-bash package provides a build-system method for debhelper that automates the non-packaging of programs for which the preferred form of distribution is the sequence "curl http://example.com/setup.sh | sudo bash -" dh-curl-sudo-bash causes debhelper to create a maintainer post-install script that runs the above command on the target machine when the package is installed. Running dpkg-reconfigure is therefore enough to upgrade the package too, thus preventing problems with upgrades. The dh-curl-sudo-bash source package Build-Depends on devscripts so that uscan can be embedded into the postinst to find the correct URL for upgrades. Example usage: debian/rules: %: dh $@ --buildsystem=curl_sudo_bash debian/curl_sudo_bash.watch: http://example.com/setup-(.*\..*).sh For completeness, other shells can also be selected by exporting the variable DH_CURL_SUDO_SHELL from debian/rules: export DH_CURL_SUDO_SHELL=mksh A future extension to dh-curl-sudo-bash is planned that will permit any github repository to be automatically (non-)packaged; the following version will iterate over all github and gitlab repositories packaging everything available. We anticipate that this will make all other Debian Developers redundant as from now on the only thing that is now required to make high quality packages for Debian is to include the relevant URL. This package also obsoletes the previous apt-gentoo package.
Re: Please add lzip support in the repository
> What is `apt-helper cat-file' and how does it help ? On stretch: $ apt-file search apt-helper apt: /usr/lib/apt/apt-helper $ /usr/lib/apt/apt-helper apt 1.4.6 (amd64) Usage: apt-helper [options] command apt-helper [options] cat-file file ... apt-helper [options] download-file uri target-path apt-helper bundles a variety of commands for shell scripts to use e.g. the same proxy configuration or acquire system as APT would. Most used commands: download-file - download the given uri to the target-path srv-lookup - lookup a SRV record (e.g. _http._tcp.ftp.debian.org) cat-file - concatenate files, with automatic decompression auto-detect-proxy - detect proxy using apt.conf Configuration options and syntax is detailed in apt.conf(5). Information about how to configure sources can be found in sources.list(5). Package and version choices can be expressed via apt_preferences(5). Security details are available in apt-secure(8). This APT helper has Super Meep Powers. $ /usr/lib/apt/apt-helper download-file http://deb.debian.org/debian/dists/sid/main/binary-amd64/Packages.xz Packages.xz Get:1 http://deb.debian.org/debian/dists/sid/main/binary-amd64/Packages.xz [7,547 kB] Fetched 7,547 kB in 5s (1,446 kB/s) $ /usr/lib/apt/apt-helper cat-file Packages.xz | less (this only looks at the repo and doesn't address package compression which Guillem discussed elsewhere) -- Stuart Prescotthttp://www.nanonanonano.net/ stu...@nanonanonano.net Debian Developer http://www.debian.org/ stu...@debian.org GPG fingerprint90E2 D2C1 AD14 6A1B 7EBB 891D BBC1 7EBB 1396 F2F7
Re: How to start a new packaging team now?
Hi Alexander, Thanks for your on-going work on alioth and its replacement. > For mailinglists? None. Currently no one is planning to provide a > replacement for mailinglists from alioth. For git we settled for gitlab. This has come up a couple of times but with little explanation and the lack of information is going to lead to wild and perhaps inaccurate speculation. I appreciate that you're waiting until the alioth replacement is ready before you announce it, but in the absence of information, incorrect extrapolations are being made. Is there some other mode of interaction that the new-alioth provides that will replace the existing mailing lists as a way for users and maintainer teams to communicate to discuss development, bugs and provide support? thanks Stuart -- Stuart Prescotthttp://www.nanonanonano.net/ stu...@nanonanonano.net Debian Developer http://www.debian.org/ stu...@debian.org GPG fingerprint90E2 D2C1 AD14 6A1B 7EBB 891D BBC1 7EBB 1396 F2F7
Re: Why do we list individual copyright holders?
Vincent Bernat wrote: > As I have said previously, the problem also appears with warnings. I > would never dare running Lintian in pedantic mode. > > Lintian is full of opinions. For example, I often get: > > W: python-pysnmp4-doc: extra-license-file > usr/share/doc/python-pysnmp4-doc/html/_sources/license.txt That is not an opinion, it is a statement of fact that there is an additional licence file in the package, that all license information should be collected in the debian/copyright file and that this usually makes it unnecessary for the package to install this information in other places as well. However, it's also not a useful fact to be telling you because sphinx- generated documentation will always have this file and while lintian is correct about this being a potential problem, it isn't actually a problem right now. Perhaps extra-license-file should be of lower severity (#740118), although if this extra licence file is one that you have genuinely missed, then it would be an RC bug or a NEW queue REJECT. (There is perhaps some irony in complaining about tools that are helping ensure that you've not forgotten a licence file in the context of complaining about getting REJECTs for not having a complete d/copyright file.) Lintian should probably learn to skip sphinx sources for this tag to improve the signal:noise on it (#885968). > Each time, more warnings appear. Just today, I get: > > W: python3-pysnmp4: > python-package-depends-on-package-from-other-python-variant (Suggests: > python-pysnmp4-doc) > > My solution? Removing the Sugggests and pray someone doesn't open a bug > to request suggesting the documentation. As noted already, that's entirely the wrong solution. It's too easy to copy+paste in debian/control and get dependencies wrong such that python3-foo accidentally depends on the module package python-bar not python3-bar. python3-foo depending on python-bar is an RC bug and *should* be flagged by lintian as such. Lintian spotting RC bugs prior to upload is a good thing. The -doc package is pretty much the only place where this cross-variant relationship is correct but that wasn't realised when that new check was written. Remember that lintian is written by humans and humans write code with bugs... they can also fix bugs when they are reported and then the tool gets better. (#885693; already fixed in git) > W: python-pysmi: new-package-should-not-package-python2-module > > This is the translation of a group of people's opinion. First, check: https://lists.debian.org/debian-python/2017/12/msg00017.html When it is the opinion of the maintainers of the Python 2 interpreter, then that's an opinion that counts. I always find that it's worth paying attention to the future intentions of the maintainers of my rdeps since what they intend to do can have an impact on my work. When the Qt4 maintainers say that Qt4 will go away, I need to do something about that; when the Python 2 maintainer says that Python 2 will go away, I need to do something about that too. I also try to avoid shooting the messenger. In adding a python 2 module package today, you're making work for your future self and for other people (python maintainers, QA team and ftp- masters at least) so it's entirely appropriate to point out that it might not be a useful thing to do. At this stage of python 2->3, new python-foo is most likely only ever going to be a leaf package with no application depending on it. The question needs to be asked: is that python 2 module actually useful for Debian to have? For the time being there's still unported code that needs Python 2 packages so one might choose to ignore new-package-should-not-package-python2-module in some carefully thought through circumstances. Lintian saying "Have you thought about this carefully" sounds pretty good. I recently had the same discussion with comaintainers of some other package and we concluded that we did need the python 2 package right now because there were going to be rdeps. python-foo-but-no-python3-foo is a much more important problem that really does need addressing *right* *now*. If it's easy to do then just do it; if it's hard to do, then now is past the time to start talking to upstream about it to make it happen. https://lintian.debian.org/tags/dependency-on-python-version-marked-for-end-of-life.html https://lintian.debian.org/tags/python-foo-but-no-python3-foo.html -- Stuart Prescotthttp://www.nanonanonano.net/ stu...@nanonanonano.net Debian Developer http://www.debian.org/ stu...@debian.org GPG fingerprint90E2 D2C1 AD14 6A1B 7EBB 891D BBC1 7EBB 1396 F2F7
Re: 50.000 binary packages
An impressive achievement indeed. I started collecting some data on source packages vs time a few years ago. It also shows some of the rhythm of the development cycle: http://ircbots.debian.net/stats/ cheers Stuart -- Stuart Prescotthttp://www.nanonanonano.net/ stu...@nanonanonano.net Debian Developer http://www.debian.org/ stu...@debian.org GPG fingerprint90E2 D2C1 AD14 6A1B 7EBB 891D BBC1 7EBB 1396 F2F7
Re: Bits from DPL
It's great to see more packages being maintained on salsa. I've certainly noticed that it is making working on packages much simpler. In my campaign, I stated [os1] that I aimed to reduce the number of packages maintained outside Salsa to below 2,000. As of March 28, 2024, the count was 2,368. As of this writing, the count stands at 1,928 [os2], so I consider this promise fulfilled. My thanks go out to everyone who contributed to this effort. Moving forward, I’d like to set a more ambitious goal for the remainder of my term and hope we can reduce the number to below 1,800. Without seeking to rain on the parade, that query is only the packages that list a non-salsa VCS. That's not counting the packages that don't list a VCS at all and therefore are also maintained outside salsa: udd=> SELECT COUNT(DISTINCT source) FROM sources WHERE release = 'sid' AND vcs_url IS NULL; count --- 2008 (both SQL "LIKE" and "NOT LIKE" don't match NULL values; there 2030 source packages in UDD that match but only 2008 distinct ones) So for completeness: udd=> SELECT COUNT(DISTINCT source) FROM sources WHERE release = 'sid' AND (vcs_url IS NULL OR vcs_url NOT LIKE '%salsa%'); count --- 3906 regards Stuart -- Stuart Prescott http://www.nanonanonano.net/ stu...@nanonanonano.net Debian Developer http://www.debian.org/ stu...@debian.org GPG fingerprint 90E2 D2C1 AD14 6A1B 7EBB 891D BBC1 7EBB 1396 F2F7
Re: Bits from DPL
'science' ORDER BY source; The vcswatch table has lots of interesting things... Note that the salsa error "could not read Username" in the table is not a misconfiguration - it means that the repo couldn't be obtained anonymously, which could be that it doesn't exist, or that it needs permissions - both are wrong for Debian. SELECT source, url, error FROM vcswatch WHERE error IS NOT NULL ORDER BY source; -- Stuart Prescott http://www.nanonanonano.net/ stu...@nanonanonano.net Debian Developer http://www.debian.org/ stu...@debian.org GPG fingerprint 90E2 D2C1 AD14 6A1B 7EBB 891D BBC1 7EBB 1396 F2F7
Re: Bits from DPL
Hi Andreas
Lets think about some better fine tuning. "NOT LIKE '%salsa%'" might
catch also Vcs URLs that are intentionally somewhere else. While I'd
love to see all packages on Salsa, it might be sensible to start with
packages that are unintentionally not in Salsa so
udd=> SELECT COUNT(DISTINCT source) FROM sources WHERE release = 'sid' AND
(vcs_url IS NULL OR vcs_url like '%alioth%' OR vcs_url like '%git.debian.org%' OR
vcs_url like '%svn.debian.org%') ;
count
---
2213
That might make a real challenge to bring that number below 2000 until
end of my term. Any help to approach this is welcome.
Well, let's look at some of these other d.o URLs.
- Not our alioth: There are 16 vcs URLs in there that have 'alioth'
in them but aren't alioth.debian.org; they are git hosted but not
on Debian infrastructure (and perhaps not in a place that facilitates
collaboration in the way being discussed)
- dgit.debian.org: There are 30 in there that are dgit.debian.org.
That surprised me, maybe I don't know enough about dgit.
- git.debian.org: There are 146 with git.debian.org - none of these VCS
URLs work any more
- svn.debian.org: !4 list svn.d.o but like git.d.o that's dead. svn.d.o
doesn't even exist as a hostname any more.
There's 161 packages in sid with old d.o URLs pointing to alioth.
There's a reasonable chance that a good portion of them are also not
maintained.
- 11% of them list their maintainer as Debian QA Group
- 13% of them have a current O bug (another 1 with an RFA)
- who knows how many are otherwise abandoned with MIA maintainers or
maintainers who have just moved on to other things
There was a recent discussion about what to do with VCSes for orphaned
packages. Maybe if it doesn't exist on salsa, it's worth creating one in
the salsa.d.o/debian/ namespace as part of doing the QA upload?
(gbp import-dscs --debsnap) That would be a good outcome and a good
little project for someone...
The vast majority of these packages have seen post-alioth uploads but
with the broken Vcs fields still in place. That's perhaps offering the
opposite of collaborative development? The question is whether the repo
has actually moved to salsa but d/control hasn't been updated, or
whether the repo has just vanished. An MBF that the VCS fields are out
of date is easy, but checking and fixing is likely manual work.
year | count
-+---
2011 | 1
2012 | 4
2013 | 3
2014 | 4
2015 | 1
2016 | 1
2017 | 2
2018 | 2 (salsa.d.o general availability)
2019 | 1
2020 |13
2021 |95
2022 |20
2023 | 7
2024 | 6
2025 | 1
I noticed that some teams have some lintian tags checking this from a
team policy perspective - doing this more broadly for other teams would
help provide teams with visibility via lintian.d.o reports.
lintian-explain-tags -t team/pkg-perl/vcs/no-git \
team/pkg-perl/vcs/no-team-url
(I accidentally found 2 python-team packages without Vcs URLs yesterday
- the repos were on salsa, just not listed in d/control)
Over half of these old alioth URLs can be addressed by Teams doing some
data normalisation and uploads:
maintainer_name | count
---+---
Debian Perl Group |72
Debian Java Maintainers|10
Debian X Strike Force | 7
Debian XML/SGML Group | 4
Debian Science Maintainers | 3
Debian CLI Applications Team | 2
Debian Ruby Extras Maintainers | 1
Debian Javascript Maintainers | 1
Debian Telepathy maintainers | 1
Debian Fonts Task Force| 1
Debian CLI Libraries Team | 1
Debian-IN Team | 1
Debichem Team | 1
NeuroDebian Team | 1
The Debian Lua Team| 1
So in terms of where to start... perhaps there's a couple of teams that
would like to do some data cleansing?
regards
Stuart
SELECT
s.source, date, vcs_url
FROM
sources AS s
JOIN upload_history AS h
ON s.source = h.source AND s.version = h.version
WHERE
release = 'sid' AND
vcs_url ~ '/(git|svn|alioth).debian.org'
ORDER BY
date DESC;
SELECT
DATE_PART('year', date) AS year,
COUNT(*)
FROM
sources AS s
JOIN upload_history AS h
ON s.source = h.source AND s.version = h.version
WHERE
release = 'sid'
AND vcs_url ~ '/(git|svn|alioth).debian.org'
GROUP BY
year
ORDER BY
year ASC;
SELECT
maintainer, COUNT(*)
FROM sources
WHERE
release = 'sid'
AND vcs_url ~ '/(git|svn|alioth).debian.org'
AND maintainer ~ '(team|group|lists)'
GROUP BY
maintainer
ORDER BY
count DESC;
--
Stuart Prescott http://www.nanonanonano.net/ stu...@nanonanonano.net
Debian Developer http://www.debian.org/ stu...@debian.org
GPG fingerprint 90E2 D2C1 AD14 6A1B 7EBB 891D BBC1 7EBB 1396 F2F7
