Re: libpaper and gnulib
On Mon, 21 Nov 2022 at 21:30, Helmut Grohne wrote: > It is known to build and run on some architectures. Excellent point! I already mitigate this risk by building most of my (upstream) packages on macOS and Windows as well as GNU/Linux, but still. And if you decide to vendor gnulib anyway, don't forget to register > yourself with the security tracker! > Excellent suggestion, thanks. -- https://rrt.sc3d.org
Re: libpaper and gnulib
On Wed, 16 Nov 2022 at 09:47, Helmut Grohne wrote: > > I think bug fixes is something you'd want. API changes less so. > My point was that there are frequently bug fixes and API changes since whatever version of gnulib is packaged in Debian. > Also note that gnulib is a piece that regularly faces portability issues > (as it tries to provide portability). As such, it is particularly > annoying for porters to not only have to fix gnulib, but then also have > to get it updated in tons of downstreams. How is this a problem for Debian packagers? Once software is packaged for Debian, it's already known to build and run. I stopped counting the number > of bug reports "... ships a broken, outdated, embedded copy of gnulib" > that I've sent. As a porter, I very much wish people wouldn't embed > gnulib. > I agree, gnulib as a whole shouldn't be embedded. I also agree that software that uses gnulib, even small parts of it (like libpaper) will have to update from time to time to fix bugs and portability problems. -- https://rrt.sc3d.org
Re: libpaper and gnulib
Thanks very much to all those who have given advice, offered help, and spelt out some of the background of gnulib use in Debian. The summary seems to be that using gnulib in its usual way to embed files used by APIs a package uses is acceptable. -- https://rrt.sc3d.org
libpaper and gnulib
I am the upstream maintainer of libpaper (which used to be a pure-Debian project), and also a Debian Maintainer trying to get a new version of libpaper into Debian. (It involves an API/ABI transition, from the current libpaper1 to libpaper2.) Bastian Germann (b...@debian.org) is kindly helping with the packaging and sponsoring my upload. I just got a rejection for libpaper_2.0.3-1 from ftp-master (in this case, Thorsten Alteholz), who said "I didn't find any explanation why you embedded a copy of gnulib in your source tarball. Do you really need that?" Like many GNU packages, my rewrite of libpaper uses gnulib, a source library that's effectively a polyfill for POSIX & GNU APIs, and my libpaper releases distribute some gnulib source files as part of the release tarball. Other Debian packages that work this way include coreutils and grep. Some other Debian packages build-depend on Debian's gnulib package. This won't necessarily work for libpaper, because gnulib is not versioned: libpaper depends on a specific commit of gnulib, and there are often bug fixes or API changes. Bastian asked me to build-depend on gnulib, which I have so far declined to do, as that would make the Debian package's sources effectively different from those that I release as upstream maintainer. Also, a build-depend on gnulib would not directly address Thorsten's problem with the package, as the source archive would still contain gnulib sources (although maybe it would be OK if they weren't used?). I had a look at a package that does build-depend on gnulib, wget2, and its source tarball contains gnulib files. I have searched the debian-devel archives and found a few reference s to gnulib, but no definitive ruling about how gnulib should be treated. Bastian rightly points out that by including gnulib sources, packages such as coreutils cannot easily be updated for security bugs in gnulib; but to me this seems to be a problem with gnulib itself (it's a source library, that's how it works), rather than with the packaging of programs that use gnulib. Another of Bastian's suggestions is that I base the Debian package on a git snapshot, as that does not include gnulib files; but this still has the problem that the Debian package would not be built from a release of libpaper. I am a bit torn here: with my DM hat on, stripping out gnulib sources where possible and using Debian's gnulib package seems the right thing to do. With my upstream hat on it leads potentially to bug reports that don't correspond to an upstream release; and further few Debian packages that use gnulib actually seem to use this method (there are 26 build-rdeps of gnulib). Help? (With many thanks to the several DDs that have already helped on the nearly 10-year journey to get libpaper updated!) -- https://rrt.sc3d.org
Re: DD(s) to help DM land some long-overdue package updates?
On Fri, 4 Feb 2022 at 14:30, Reuben Thomas wrote: > > Having just now got the new Debian packaging building without error, I > shall now follow the ITS procedure and see what happens! > I have waited 8 days since posting debdiffs, and had no response, so I've now filed an ITS bug: #1006481. -- https://rrt.sc3d.org
Re: DD(s) to help DM land some long-overdue package updates?
On Sat, 1 Jan 2022 at 22:34, Reuben Thomas wrote: > On Sat, 1 Jan 2022 at 20:43, Pierre-Elliott Bécue wrote: > > > > I suggest this path: > > > > Send bug reports with your debdiff proposals for each package. If 8 days > > after you get no reply from the maintainer, file an ITS against the > > packages for which you got no reply. > > > > If at the end of the process, the ITS pass, I'll make your uploads > > after reviewing the changes. > > Many thanks, I'll try to do this. > I thought I should give an update on my progress: Santiago Vila started work on packaging recode 3.7, one of the packages I mentioned, so I did some work to help with that. That has actually taken most of my time until now. However, I have also found some time to work on the packaging of mmv. I think this is one of the clearest-cut packages in the list I mentioned: I am the (new) upstream of mmv, and I have made a new release. Having just now got the new Debian packaging building without error, I shall now follow the ITS procedure and see what happens! -- https://rrt.sc3d.org
Re: DD(s) to help DM land some long-overdue package updates?
On Sat, 1 Jan 2022 at 20:55, Wookey wrote: > > Hi Rebuen. I helped you with the last libpaper refurbishment in > 2012-2014. Happy to do that again, although as people have pointed out > complete rewrites are not really NMU material and we should follow the > salvage process. > > Well done for getting those boring old packages into better shape (again). Many thanks! I'll follow up PEB's offer, and see what happens. -- https://rrt.sc3d.org
Re: DD(s) to help DM land some long-overdue package updates?
On Sat, 1 Jan 2022 at 20:43, Pierre-Elliott Bécue wrote: > > I suggest this path: > > Send bug reports with your debdiff proposals for each package. If 8 days > after you get no reply from the maintainer, file an ITS against the > packages for which you got no reply. > > If at the end of the process, the ITS pass, I'll make your uploads > after reviewing the changes. Many thanks, I'll try to do this. -- https://rrt.sc3d.org
Re: DD(s) to help DM land some long-overdue package updates?
On Sat, 1 Jan 2022 at 19:48, Boyuan Yang wrote: > > That being said, while providing a list onto debian-devel is not a bad idea, > https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#package-salvaging > should be the correct choice. For a specific example, I just spotted > https://bugs.debian.org/961136 the second time (last time back in May 2020); > let me know if you would like to initiate a package salvaging process on this > certain package and I can help. Thanks very much for the pointer! I was not aware of this process. It might be appropriate for me, I guess, but I'd still need DD help. -- https://rrt.sc3d.org
DD(s) to help DM land some long-overdue package updates?
I'm a long-term Debian user and upstream maintainer, and a DM. I'm working to package updates to mature packages. All of them have maintainers who are at best sporadically responsive—I do not blame them! I'm sure they're all hugely overworked. (I'm also upstream for several packages with responsive maintainers who are all excellent at packaging new releases.) I've contacted various DDs who have helped me in the past, but over the last few years they've all been unresponsive too—again, I'm sure they are all swamped with higher-priority things to do. In particular, if you're the maintainer of one of the packages I mention, and you're reading this, please don't take this appeal as any sort of criticism! If you've not had a recent communication for me, it may just be a spam trap problem—do get in touch if you can! Here's a summary of the packages I'm trying to update. If any DD can help me get these uploaded, I'd be most grateful, it should also be good for users, as the upstreams I maintain contain in some cases many years of fixes and improvements relative to the current Debian version. In all cases, I'm happy to do the Debian packaging work too, and I have up-to-date packaging for most of the packages. * recode: recode 3.7 contains many years of fixes and improvements over the packaged 3.6, since the death of recode's author, François Pinard. The current release fixes almost all the outstanding issues in the BTS. * libpaper: I have completely rewritten libpaper, while keeping it compatible with the current version. It is more friendly to users, who can now have their own custom paper sizes, and to programs written in languages other than C, which can use it via the new "paper" command. * psutils: I have rewritten psutils in Perl (was in C), fixing bugs, and moving most of the functionality into pstops(1); most of the commands are now implemented as invocations of pstops. * finddup: this package used to be called perforate; it was removed from testing on 27th December. I renamed it (the old name confusing, as there was no "perforate" command, and these days the most useful functionality is the “finddup” command), fixed bugs, and simplified the code. * mmv: I have added the ability for mmv to rename directories, fixed bugs, and simplified the code. I really just need a sponsor for uploads and any other parts of the process (e.g. review of "finddup" as it's technically a new package) that I can't do myself as a mere DM. Feel free either to reply to this message or drop me a line directly; thanks in advance to anyone who's able to help! -- https://rrt.sc3d.org
Accepted python-ewmh 0.1.5-1 (all source) into unstable, unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Sat, 29 Oct 2016 18:42:15 +0200 Source: python-ewmh Binary: python-ewmh python3-ewmh python-ewmh-doc Architecture: all source Version: 0.1.5-1 Distribution: unstable Urgency: low Maintainer: Debian Python Modules Team <python-modules-t...@lists.alioth.debian.org> Changed-By: Reuben Thomas <r...@sc3d.org> Closes: 749713 Description: python3-ewmh - Python interface to EWMH-compliant window managers (Python 3) python-ewmh-doc - Python interface to EWMH-compliant window managers (common docume python-ewmh - Python interface to EWMH-compliant window managers (Python 2) Changes: python-ewmh (0.1.5-1) unstable; urgency=low . * Initial release (Closes: #749713). Checksums-Sha1: 4bb6608ab90bb2b6d0f59f07419d626c33575ae4 1950 python-ewmh_0.1.5-1.dsc 47f89d680ea42393d9fddd7e2a23624a394c95c2 12712 python-ewmh_0.1.5.orig.tar.gz 8cde28ef3b1e10ab907d5dd9b7746626d78dbbe4 1864 python-ewmh_0.1.5-1.debian.tar.xz 82f29b9275533a35b7c71f2d0bb9f33f4480e9b7 21918 python-ewmh-doc_0.1.5-1_all.deb 742f037f066bf36852815b07f00a53f3f4d42a40 6708 python-ewmh_0.1.5-1_all.deb cc36551c6e69d2757fba9209e5ea8d611ae985a4 6796 python3-ewmh_0.1.5-1_all.deb Checksums-Sha256: 20f7e9c953b1c2e558d29f74de92d3a8a8daf832f38f709cd2ecedf188f692ff 1950 python-ewmh_0.1.5-1.dsc 0735566d49191a69a00ea74f56b14f36d7d830317888312ec15b9ed6c29f768d 12712 python-ewmh_0.1.5.orig.tar.gz 88e93d8e807d8a41dd966aa077092af0c9628c4a89726458b13ee4e0f3b21a80 1864 python-ewmh_0.1.5-1.debian.tar.xz d81523e1d3c665414f9006215b92bf8837bb4e0e0c382f873c838da9336816c9 21918 python-ewmh-doc_0.1.5-1_all.deb becfdc1a8df0c64d220e1bd3c9407c0602cb2f05e71bfc4055ff7f1536f1422c 6708 python-ewmh_0.1.5-1_all.deb 387d67766585076b2dcb8dfc4818854204fedb47ab1089384679fbea68f9cdca 6796 python3-ewmh_0.1.5-1_all.deb Files: 5151fb8ad22a4706d8f1c0342acd5db4 1950 python optional python-ewmh_0.1.5-1.dsc 33a81b592ae2ab956eb46fbc49f78414 12712 python optional python-ewmh_0.1.5.orig.tar.gz 36016821636914d8c1e85a07348a5865 1864 python optional python-ewmh_0.1.5-1.debian.tar.xz f97dc457e99b1347d52fe70f24e1a516 21918 doc optional python-ewmh-doc_0.1.5-1_all.deb 5d4a9abb3b32d0466f552606519fc77e 6708 python optional python-ewmh_0.1.5-1_all.deb ee317a0bcf4a6f1e05a795c24ff059d3 6796 python optional python3-ewmh_0.1.5-1_all.deb -BEGIN PGP SIGNATURE- iQEcBAEBCAAGBQJYFcr9AAoJEJ1bI/kYT6UU5egH/1/fE/LgPV4OE0+jskOCL8aY LfAuAN/dv4iYrjuVu65I8rt74gcC/rMfA1TFIng26eMc4SXm6ubouy6xNqw/Wlyo WYNd4/zHkBdX8071jVcdjbh8QLcjO+HF/EzS9243L7njrQZifEHhkteGC7Xj3Sj7 owF01f7/Uwz6zF2vkZBsclFafPMAXM5qD1gQ7ykkTLrMDUU8upAqW5lp6CNG7hce uTZXUbuwIyejx2u+5qdE5Ldz8YZakvcshLddO8IhDaGLAq7b/jNKnURI80BeUcHH s47PH17X1y1w+Gv7fWcflx9eAxXDyJh71nhRM7UiQdeG1UZxIXHD+mfkgU10CAA= =pb5n -END PGP SIGNATURE-
Re: BSP - chasse aux bugs - Novemb{re,er} 14-16 2014, Paris, France
2014-10-17 19:10 GMT+01:00 Sylvestre Ledru sylves...@debian.org: The English version is at the end of the email. Next November, 14 to 16th, a Bug Squashing Party (BSP) is organized in Mozilla offices [1] in Paris. That should be This November. -- http://rrt.sc3d.org
Accepted plptools 1.0.13-0.1 (source amd64) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Tue, 22 Jul 2014 15:47:33 +0100 Source: plptools Binary: plptools Architecture: source amd64 Version: 1.0.13-0.1 Distribution: unstable Urgency: low Maintainer: John Lines j...@paladyn.org Changed-By: Reuben Thomas r...@sc3d.org Description: plptools - Access EPOC device (Psion PDA) over a serial link Closes: 238921 593791 716591 718756 727942 732299 Changes: plptools (1.0.13-0.1) unstable; urgency=low . * Non-maintainer upload. * New upstream release 1.0.13. (Closes: #732299) * Fix plpfuse missing on 64-bit archs. (Closes: #593791) * Fix a bug preventing plpfuse working with EPOC16 machines. (Sourceforge bug #62) * Fix a crash in plpfuse. (Closes: #716591) * Add Japanese debconf translation. (Closes: #718756) * Update packaging to debhelper 9, Debian policy 3.9.5. (Closes: #727942) * Fix handling of *_ARGS variables containing spaces in /etc/default/plptools, and use correct flag to plpprintd for print command. (Closes: #238921) * Remove -dev package, which is unused and has no (build-)deps. * Fix race condition during package upgrade. Checksums-Sha1: e43a4d8127c335a19e175dd9feddc873b65c6952 1854 plptools_1.0.13-0.1.dsc 10809044aa505bb5dc9574182311bf534e11ca8f 840724 plptools_1.0.13.orig.tar.gz 0343bbbd562cc8f73c4a432964dfacf2c3d62451 25832 plptools_1.0.13-0.1.debian.tar.xz 214f804674c2e7c74f75097d2a8d4f8df6831cc2 232258 plptools_1.0.13-0.1_amd64.deb Checksums-Sha256: 471dd1a5fb8c97452519c71839016665be1ffea1a5ede458443fda08512a 1854 plptools_1.0.13-0.1.dsc 3a4309c1d7f7607340bc54dbaaaeaa8ce144ef5f22d37678feb302ece75253ed 840724 plptools_1.0.13.orig.tar.gz f6ddcedf751c73e6a892ee17a2befb7513bd2b6c0f58c146d81b33c82580c35a 25832 plptools_1.0.13-0.1.debian.tar.xz a53afa160ca2c099ccf957a62843eb731a63c582042597e17fbfdc03e7c8c17b 232258 plptools_1.0.13-0.1_amd64.deb Files: d1e7d41296f8d530422798bfda5c78ba 1854 otherosfs optional plptools_1.0.13-0.1.dsc 7e5efff56bef2a6eab60db93c56746a9 840724 otherosfs optional plptools_1.0.13.orig.tar.gz 233aac62b03d3f41ecbc7db9d8fe9630 25832 otherosfs optional plptools_1.0.13-0.1.debian.tar.xz a8f8c2b3732e82713c85292a002408e0 232258 otherosfs optional plptools_1.0.13-0.1_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBAgAGBQJUPdvPAAoJEPuGMlGob55HCg0QAL+6yl5JXyKjcbyGS7oP0tGl 5TIFGB2T52vXlmtITfq4SKQxM2+gOf8ajNJ5eWkVDcYDlJXWCBuA5zXBeoNE9A8G IrZXgzMmKsPUb7BwhwldlKXvWGbpmTP+X2vsWekYJW1o0dwtz48ra7rWglcBXQG6 Eu7mwFhghwdtNXOeFYHa8W0l8Tb1uotQhDo3S6igLEtllCSymSZYkLQ/b1YxBDeT hLSuw42MnPhD+Obu7cv6rrXutFe/DLA0kr/pQaz9SWe5tWzzTB4LxhZL5SzzQjat VvMkpyzT2HMqGAHRg1dRuDYJKdH95kVsEf31x/epmstRvbMQ7vi0FRP+Zk4fEwEt Sv3KGCqGNDJxWm/G4CqL3ZGkmOepPBccSBM2y2tika2vErvYiBz3FTo1xxsC9onu qL2oaRoNsGidqOd0EwVENg/IRrOVdn9G0H2yXJXhxW38ZEaCC79U+A5SJRoirBHX SNbJyTFaIFMBGaUfSkYcTo2VFsUYmyoDfbHhxuDaUVQdRIv0VF5BpXuwXvHs5de+ 2cgJwrap9aqHBZoSCJKzy135O57Ko9vR/MS6BzHEgcO6qLJq4yiNt9Jde5CrOgRF h7jV3BrC+GQsunyIjqsyilwT0Nxn3CLfOL0Bp4La4RGqd+CuljmEEPSkrDqS7mkW aH1FdBdT5uUnUZO4e6Ia =oxf9 -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/e1xeokv-0002bz...@franck.debian.org
Bug#749713: ITP: python3-pyewmh -- Python3 implementation of Extended Window Manager Hints
Package: wnpp Severity: wishlist Owner: Reuben Thomas r...@sc3d.org * Package name: python-pyewmh Version : 0.2 Upstream Author : Julien Pages parco...@users.sourceforge.net * URL : https://github.com/parkouss/pyewmh * License : GPL Programming Lang: Python Description : Python3 implementation of Extended Window Manager Hints This Python3 module implements Extended Window Manager Hints on top of python-xlib. This package is a dependency for Caffeine, which is currently packaged in an Ubuntu PPA: https://launchpad.net/caffeine I intend to package Caffeine for Debian. Caffeine currently includes pyewmh in-tree, but it would obviously be better to package it properly. The package is useful for implementing window managers or extensions to them in Python; I'm not aware of any other similar package, in Debian or not, above the level of python-xlib, on which this package is based. I will need a sponsor for this package. It is mature, so not much maintenance is required. -- 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/20140529113139.14804.2608.reportbug@skwd
Re: Bits from keyring-maint: Pushing keyring updates. Let us bury your old 1024D key!
On 3 March 2014 18:13, Gunnar Wolf gw...@gwolf.org wrote: As keyring maintainers, we no longer consider 1024D keys to be trustable. We are not yet mass-removing them, because we don't want to hamper the project's work, but we definitively will start being more aggressively deprecating their use. 1024D keys should be seen as brute-force vulnerable nowadays. Please do migrate away from them into stronger keys (4096R recommended) as soon as possible. Please could you change https://wiki.debian.org/DebianMaintainer , which currently says a = 2048 bit key is required (I assume this is still correct) but does not specifically recommend 4096? I recently became a DM, and created a 2048 bit key to do so, as that satisfied the advice given on that page, and also happened to be the default length offered by GPG on my system. Only after I'd had it signed and uploaded it did I find advice that new keys should be 4096 bits. (I've already reported this issue in a couple of different places; the page is not user-editable or I'd've fixed it myself!)
Re: Bits from keyring-maint: Pushing keyring updates. Let us bury your old 1024D key!
On 3 March 2014 20:01, Steve Langasek vor...@debian.org wrote: Done. The page is user editable, provided that you're logged in to the wiki. Thanks. I'm sorry, I was confused: I think the real reason I didn't edit the page was because at the time I didn't know whether it or the other material I had read was wrong; I did indeed go round this loop a few months ago with the Debian wiki saying that a page was locked when it really meant I hadn't logged in, and my brain clearly hasn't recovered. -- http://rrt.sc3d.org
Re: Compiling packages for the standard distribution with -Os instead of -O2
I thought it might be worth pointing out that this has already been done on a large scale, in Mac OS X. That is precisely why PPC and i386 gcc are now largely fixed. Also, that the Mac OS team did considerable testing, and now build almost everything with -Os. I heard this at a presentation from one of the developers involved, in London: it was Eric Albert, at this UKUUG event: http://www.ukuug.org/events/apple06/ but I can't find a copy of the slides on the web. -- http://rrt.sc3d.org/ | Crews help mock terror casualties (BBC) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
