Re: migration from cron.daily to systemd timers
On Wed, Jan 8, 2020 at 11:45 PM Richard Laager wrote: > We do lose the automatic cron emails This is the main reason I haven't switched to systemd timers for my personal crontab, I have some jobs that generate output (diffs of various things mostly) but don't fail. There doesn't appear to be any tool to monitor a tool and send a mail if it generates output or fails, in the way that cron does. As the blogs you link to explain, even if such a tool existed, systemd's options for output handling don't really allow for such a tool to be passed the output easily. -- bye, pabs https://wiki.debian.org/PaulWise
Re: Cross-build Qt Debian package
On Wed, Jan 8, 2020 at 12:21 PM Lisandro Damián Nicanor Pérez Meyer wrote: > On Wed, 8 Jan 2020 at 06:51, Carsten Behling wrote: > > > > I get the following error while trying to rebuild > > 'qtbase-opensource-src_5.7.1+dfsg-3+deb9u1' for Debian Stretch armhf in a > > pbuilder environment: > > qtbase can't be cross built "as is" in Stretch, and possibly not in > Bullseye either. That will most surely change with Qt 6. CrossQA indicates that isn't possible in bullseye either, looks like it uses the compiles for the build arch instead of the host arch, so it finds the wrong libraries and doesn't find some headers for the host arch. http://crossqa.debian.net/src/qtbase-opensource-src -- bye, pabs https://wiki.debian.org/PaulWise
Re: https://tracker.debian.org/pkg/dballe
On Mon, 2019-12-30 at 11:29 +0100, Kurt Roeckx wrote: > Is it .deb and .changes file that you would move? That would be the idea yeah. > Note that the name of the .changes file by the maintainer and the > buildd will be the same, and dak will reject it if that .changes > file already exists. I expect that could be dealt with easily in the dak patches, for e.g. by renaming the .changes to include the fingerprint of the signing key or by naming the morgue directory after the signing key fingerprint. -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Re: https://tracker.debian.org/pkg/dballe
On Sun, Dec 29, 2019 at 1:29 PM Roberto C. Sánchez wrote: > Would it not be possible to eliminate the need for the second > unnecessary upload by requiring two signed .changes files to go into > NEW? A signed binary changes which would form the basis of the FTP > master review and a signed source changes to enter the archive if the > package is approved? Another approach is to simply have dak discard binaries from all sourceful uploads (in dak parlance that means .changes files that have a .dsc) (and save them to an audit directory). The buildds currently only produce non-sourceful uploads so all their binaries get accepted fine. For bootstrap scenarios, maintainers can just do an additional binary-only upload. See the patches myself/ivodd posted recently for a work in progress on this. -- bye, pabs https://wiki.debian.org/PaulWise
Re: https://tracker.debian.org/pkg/dballe
On Sun, Dec 29, 2019 at 11:32 AM Paul Gevers wrote: > [1] Source packages that build binaries unknown to the archive currently > need these binaries to be uploaded by the maintainers for reviewing by > ftp-master in NEW. IIRC there have been multiple proposals to avoid > these binaries from either being needed or being uploaded to the Debian > archive, but so far the current tooling requires this. There has been some recent work on this part of the problem, I focussed on throwing away binaries for all sourceful uploads and ivodd focussed on doing that for NEW uploads only. Since ivodd's patch is further along than mine, I hope he will extend it to all sourceful uploads. https://lists.debian.org/msgid-search/5ec2e979cd7d7ec9bf386fbf77e3399c7aeeb473.ca...@debian.org https://salsa.debian.org/pabs/dak/commits/discard-binaries https://lists.debian.org/msgid-search/87sgm2lhwc@marvin.43-1.org https://lists.debian.org/msgid-search/de353950121612a86ca706cbdf36153b25b9fa36.ca...@debian.org https://lists.debian.org/msgid-search/27641434-e45a-404f-254f-daea89916...@debian.org https://salsa.debian.org/ivodd/dak/tree/new-throwaway-binary-v10 -- bye, pabs https://wiki.debian.org/PaulWise
Re: requirements and regulations concerning upgrade checks/statistics callback on program start
On Sun, Dec 29, 2019 at 12:42 AM Robie Basak wrote: > I file serious bugs when I discover this kind of behaviour in Debian > packages. I've come across this only twice, but I've never spent time > actually looking, so perhaps there are many more? I expect there are quite a few more, some listed on the wiki: https://wiki.debian.org/PrivacyIssues > I was unable to find anything in policy either, but I take the position > that, if asked, Debian developers are likely to take a similar position, > and it has just never come up because maintainers haven't (as far as I'm > aware) objected to treating this behaviour as a serious bug. Has any > maintainer specifically objected? Please document objections on the wiki page if you see them. > Here are mine: > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=778947 > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=935042 I have added these to the privacy usertag: $ bts user debian-devel@lists.debian.org , usertags 778947 + privacy $ bts user debian-devel@lists.debian.org , usertags 935042 + privacy https://wiki.debian.org/PrivacyIssues#Reports -- bye, pabs https://wiki.debian.org/PaulWise
Re: requirements and regulations concerning upgrade checks/statistics callback on program start
On Fri, Dec 27, 2019 at 6:01 AM Norbert Preining wrote: > Upstream states clearly what he is collecting, and the rest is obvious > because displayed on start. No magic necessary. > Also no hidden stuff, all is clearly stated and open. That sounds reasonable then. > What do you mean with "informed consent and correct behaviour"? I would expect something like this: in the user interface (help menu perhaps, or on first start), have a button "send usage feedback" (or similar) that when pressed displays a page containing the exact data set that is proposed to be sent, what other information is captured (or expressly not captured) by the server (IP address etc if anything) in the sending process, list information about what all that information is used for (with a link to the stats etc) and buttons for confirming sending the data and for cancelling sending. > Would a clear statement in the NEWS file be enough? That is unlikely to reach all users of the package, but would be helpful if the data collection is opt-out rather than opt-in. > I read through that case and I consider it quite different. In the Cura > case quite a lot of information where sent, while in the Calibre case > there is only a random ID, the OS (no specifics, just > Linux/Windows/Mac), and the iconset selected (if any) which has > influence only on the order of selectable iconsets in the menu ;-) > > No information about the library (not even the number of books). Indeed, sounds fairly different. Is there any information about what the random ID is, how it is generated and if it gets copied around in sync scenarios? -- bye, pabs https://wiki.debian.org/PaulWise
Re: requirements and regulations concerning upgrade checks/statistics callback on program start
On Thu, Dec 26, 2019 at 5:52 AM Norbert Preining wrote: > Calibre is normally doing the following checks: I am wondering how you discovered these, was it just reading the upstream code/website or are you monitoring traffic on your machine? Personally, I think we need much more systematic auditing of these sort of issues as more and more upstreams are adding update checks and usage reporting and other statistics and telemetry. We also need better tooling for discovering the issues, unfortunately nsntrace was removed from Debian and opensnitch/unoon aren't packaged yet. https://github.com/jonasdn/nsntrace/ https://github.com/kushaldas/unoon/ https://github.com/evilsocket/opensnitch/ > Which of the above actions are acceptable for Debian/main? Personally, I don't like any of them enabled by default but with informed consent and correct behaviour the plugin update checks could be reasonable for the Debian package. The general update check isn't useful on Debian but could be for some of the upstream platforms that don't have system-wide package update checks. In case you want to convince upstream to correct the behaviour, here is an example of somewhere that upstream was (eventually) convinced to make their telemetry much more reasonable, but IIRC their change of heart about that was mainly due to the GDPR and not driven by their developers being convinced by folks suggesting the change in the issue tracker. https://github.com/Ultimaker/Cura/issues/2810 -- bye, pabs https://wiki.debian.org/PaulWise
Re: Requesting to take over maintenance of lilo
On Sat, 2019-12-21 at 08:42 -0800, Joshua Hudson wrote: > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=861053 I think it would be appropriate to add some more information to this bug to make it easier to understand and take action on. These bits of information would help: The output of both these two commands: sudo /usr/sbin/grub-mkconfig -o /root/grub.cfg sudo sh -x /usr/sbin/grub-mkconfig -o /root/grub.cfg The generated grub config file. > I have less resources than Joachim Wiedorn , but it looks like > maintaining lilo is very little work. The upstream source (same > person) had its last release in 2015. Since Joachim is also the upstream maintainer of lilo, it would be a good idea for someone to take over maintaining it upstream too if it is to continue being available for use in Debian. -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Re: Requesting to take over maintenance of lilo
On Sat, Dec 21, 2019 at 5:21 AM Joshua Hudson wrote: > Basically, the existing package maintainer doesn't want to maintain > lilo anymore, says "will disappear by end of 2020" You might want to read through the thread about this if you haven't yet: https://lists.debian.org/msgid-search/2019193422.2852b...@jupiter.home > I have some hardware that update-grub just doesn't understand Please report a bug about it if you haven't done that yet. > a locally modified lilo that has support for it. Is the modification likely to be break lilo for other folks or is it suitable for distribution in the Debian package? > I want to take over lilo maitenance so that apt-get update integration > continues to work. Please contact the current lilo maintainer about this and also read through these documents: https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#adopting-a-package https://mentors.debian.net/intro-maintainers -- bye, pabs https://wiki.debian.org/PaulWise
Re: Packaging text licenses
On Tue, Dec 17, 2019 at 9:25 PM Thomas Goirand wrote: > If we are already shipping the license (non-free) text as part of > packages, what difference would it make to have them all shipped in a > single package? Can't the exception also apply to that one package Jonas > is suggesting? One difference is that in the normal case, the license often says we *must* ship a copy of the license when shipping a copy of the software. In the case of a package that ships copies of licenses without the licenses applying to anything in the package, that obligation doesn't exist. Personally, because of the above consideration, I consider that probably collections of licenses shouldn't be shipped in main. OTOH, base-files: /usr/share/common-licenses/ exists so perhaps Debian already ignores this issue. -- bye, pabs https://wiki.debian.org/PaulWise
Accepted libpst 0.6.71-1 (source) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Mon, 16 Dec 2019 14:49:09 +0800 Source: libpst Architecture: source Version: 0.6.71-1 Distribution: unstable Urgency: medium Maintainer: Paul Wise Changed-By: Paul Wise Closes: 792257 856524 Changes: libpst (0.6.71-1) unstable; urgency=medium . [ Ondřej Nový ] * d/changelog: Remove trailing whitespaces * d/control: Remove trailing whitespaces . [ lintian-brush ] * debian/copyright: Replace commas with whitespace to separate items in Files paragraph. * Use secure URI in debian/watch. * Bump debhelper from old 9 to 10. * Fix day-of-week for changelog entry 0.6.52-1. * Use secure URI in Homepage field. * Drop unnecessary dependency on dh-autoreconf. . [ Paul Wise ] * Add some upstream metadata * Use more correct, secure URI in debian/copyright * Adopt the package (Closes: #856524) - Thanks to Leo Costela and others for earlier maintenance * Slightly expand the libpst-dev package description * Declare the package doesn't need root to build * Document compliance with Standards-Version 4.4.1 * Document -dev package in symbols file * Declare the copyright file as machine-readable * Mark the -dev package as Multi-Arch: same * Correct list of formats supported by readpst (Closes: #792257) - suggest mb2md for providing conversion to Maildir * Enable all hardening options * Clean up the copyright information file * Switch to debhelper-compat and version 12 * Install the upstream NEWS file too Checksums-Sha1: 217ce5d9d43db3197229f3b47ff93baa109fa274 1975 libpst_0.6.71-1.dsc ada2fac08183dd9ce94279fb660b3b009c7b4272 5784 libpst_0.6.71-1.debian.tar.xz 11d1cda9a20959d88dcc4bb2b9d3fbb93df0743c 10691 libpst_0.6.71-1_amd64.buildinfo Checksums-Sha256: e1b5faf41ebe8860ca36c5000167bbfef15d69a1981faef303b31eca8449d7f1 1975 libpst_0.6.71-1.dsc 0cd86adc04836a9181447eccdbf6b04acd011bc36b6904dade08156c1c79f91f 5784 libpst_0.6.71-1.debian.tar.xz c04a7307401e3150875f12069e06f0d4ac5c5c198dbab11a95add7433d890487 10691 libpst_0.6.71-1_amd64.buildinfo Files: 489be14e07bd7db9fa9a9e7201fc9a63 1975 utils optional libpst_0.6.71-1.dsc 90538716fed1fce4c1c41078deb3f7a2 5784 utils optional libpst_0.6.71-1.debian.tar.xz 6fd12bf3026e42db90586381503e9d0b 10691 utils optional libpst_0.6.71-1_amd64.buildinfo -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEYQsotVz8/kXqG1Y7MRa6Xp/6aaMFAl33L88ACgkQMRa6Xp/6 aaPuFA//SWiE5PrgPLe4w/1PBmQ/hpU05W+8crWQAZCO74HKlse/wMouH7u7+ZzP hiX/4BCDIGVQkXBHS7cFo0iyJyXcaYm0o+/YxKkcMBncm9up417Lc2wJneGVIYiD XCJqEPpOqnB1RLoQ+4nqpf6I5aChnfk/MLoSScu1ppUH9wkDf1SCouJXYAXwBXFw qacd/dSGbkfeow3cvcPPsOTmhTm+jIJF8CFDMFvKeGu01IMQX66xFOy0XiEtaLJf h/yb1DVqYrJFhZJExbV23Mz/iSwanK382WZs9z/6jhuz05K1vWSTy9/VcOPTQR+j i2BLLe4i40k78shGl1hXvUNCJWm2LFSC0uwWttCO0SIXd7cYJz+LVDELyn830xOY 0mDU2BJTrzhFYNRMioEt/H69sR++nQmep0ZIrV4UEEzy5xNjdLJXDpUP40YdOc0t 27iz4zyHMSpFmwaJq+5Lb/1lrKVx/zGyorjXmP1atDypqYrratHgzf0u+W51EwbE f8ADpQiaDBQA0qwVSN0AcYQQtOubNTUBpBo/qBkXPGND1WLnPXamjWv8oz7kNTDo EWdoeqaej2kjTyWaySXMySC4Xcg1QT/uoxR0BLpWQrQv+Ilo+EhcQgfoKLhAdYks E2lw7lN3bQhorEUHuW/xSMzmM9vISVggwsYPx6KAI7lA1bXgzvc= =LNc/ -END PGP SIGNATURE-
Accepted libforms 1.2.3-1.4 (source) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Mon, 11 Nov 2019 10:33:39 +0800 Source: libforms Architecture: source Version: 1.2.3-1.4 Distribution: unstable Urgency: medium Maintainer: Peter S Galbraith Changed-By: Paul Wise Closes: 941535 Changes: libforms (1.2.3-1.4) unstable; urgency=medium . * Non-maintainer upload. * Switch from texlive-generic-recommended to texlive-plain-generic (Closes: #941535) Checksums-Sha1: 3d02fddd8a38dd5c21e190f33c43f249b47aef78 2231 libforms_1.2.3-1.4.dsc e3dae6f8099f1a756af327a3b5f2b2afd5e0b728 5988 libforms_1.2.3-1.4.debian.tar.xz Checksums-Sha256: b97c32a50364e794468185c804edc8e03ac2b8cfde2c6a0346cc578da02c0dcf 2231 libforms_1.2.3-1.4.dsc 296b2fc1ab022f29ce3b93eccf74de607c6c21453f63e498d1d30148da01d119 5988 libforms_1.2.3-1.4.debian.tar.xz Files: a8545f23c6f06ebfd9d4d8cca8a0e803 2231 libs optional libforms_1.2.3-1.4.dsc 2734b803be614f5f30ab36707235192a 5988 libs optional libforms_1.2.3-1.4.debian.tar.xz -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEYQsotVz8/kXqG1Y7MRa6Xp/6aaMFAl3IyYYACgkQMRa6Xp/6 aaPzKQ//QDKiPiqbUkofVB0dV5ySwGOloDv9wBee1/VDYyUaLuxYXS4NzZNFRJpg 0YuFMCChGWCLdn7+t4g3aHu28IMcPA17OV3IJM12iPqC1vMkqyWugijetfpQMdBM lHp2ENIr6yTTK5xC93O3ty06Gz5Xx2bdCmBmXcDYQb7dYgRJuCiIkq7Of8WO6mls KNk7eatErm7uGxacyj/1gDdckpsvu6SLE/lgPfghBW21ptKXo7tbU1uRWf/uAzlg NhTV+GPvM2pJ4cDEb3JMKyiErwr0MbPgX2E8S2RmdmjGj2vPFRq3xQBla6WfzAfQ iPoyMBH4J74h/D3k+WR4M0iW4lWNAtVgbXNa6wnUlVNZbzYr4a1dyhG/BYFmBTlA Pni3f6291tvSOoq6hTWfEMz/njhd04yZbEt+pvKqDFpCJTUQHqhh7NjDA7XLRXkl GuJJ1a3efdMiF6uTdTfILfFCK9xS92bxieKBMkRYSYkCpCKVxoHCEHMnUVToR43k MfWLUmriL9zqmaJo+6B37wLjxbbJ1Z7LdAZ1ynoYrkmrh7fYDiJ7CFlsIodvPXwW lN6Xa7GACvMrnIhsECjp2W9li7PsSL2adrfImpnyZsoPIQu/BYPfieEtqQ89jP+e 5N4tRoGWOWf2zRlGMyVDLpt3cabIgmEAO+wqYqbu0HNgHbsVdtQ= =kaSA -END PGP SIGNATURE-
Re: Usage of DEP5
On Sun, Nov 10, 2019 at 1:40 AM Russ Allbery wrote: > Maybe one of these days I'll take a couple of days and turn it into > something vaguely maintainable and usable by someone else. We already have a lot of similar tools for this, unfortunately the most accurate ones (FOSSology & ScanCode) aren't available in Debian right now, although folks are working on that. FOSSology has an ITP & RFS and a GSoC student apparently worked on or is working on ScanCode packaging. ScanCode doesn't yet support the Debian copyright output format but FOSSology does. https://wiki.debian.org/CopyrightReviewTools https://lwn.net/Articles/803725/ https://osr.cs.fau.de/2019/08/07/final-thesis-a-comparison-study-of-open-source-license-crawler/ https://bugs.debian.org/924659 https://bugs.debian.org/926915 https://github.com/nexB/scancode-toolkit/issues/469 https://github.com/nexB/scancode-toolkit/issues/472 -- bye, pabs https://wiki.debian.org/PaulWise
Accepted purple-discord 0.9.2019.11.04.git.6552cde-1 (source) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Fri, 08 Nov 2019 10:03:39 +0800 Source: purple-discord Architecture: source Version: 0.9.2019.11.04.git.6552cde-1 Distribution: unstable Urgency: medium Maintainer: Paul Wise Changed-By: Paul Wise Changes: purple-discord (0.9.2019.11.04.git.6552cde-1) unstable; urgency=medium . * New upstream snapshot * Bump Standards-Version, no changes needed Checksums-Sha1: 078a09f688947ec758311dad9d0db76afb849962 1999 purple-discord_0.9.2019.11.04.git.6552cde-1.dsc bded6c028f5c9d08ce8c439b50720398d109a414 70967 purple-discord_0.9.2019.11.04.git.6552cde.orig.tar.gz 33f858fdee4305998553e7dd8dd14bd7ea6c03f3 2612 purple-discord_0.9.2019.11.04.git.6552cde-1.debian.tar.xz Checksums-Sha256: da3f23b78c126417d599491fd6e0ed241942c815eee34d79662be5d120ead1e4 1999 purple-discord_0.9.2019.11.04.git.6552cde-1.dsc b358e610121a29f7339da027bd2654faf1b3b32619f930d616785a732fb8be76 70967 purple-discord_0.9.2019.11.04.git.6552cde.orig.tar.gz 5652cf42da5c6aa5bf95ab8f1daf00fb18efe6c065572170f5df263d55780e44 2612 purple-discord_0.9.2019.11.04.git.6552cde-1.debian.tar.xz Files: 7278e92144f94ea873197a2356650e74 1999 net optional purple-discord_0.9.2019.11.04.git.6552cde-1.dsc 29dfb16dc5a6ac98fa90c5cd7594f292 70967 net optional purple-discord_0.9.2019.11.04.git.6552cde.orig.tar.gz 33133e44131f5f4c5930e719e78cdf34 2612 net optional purple-discord_0.9.2019.11.04.git.6552cde-1.debian.tar.xz -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEYQsotVz8/kXqG1Y7MRa6Xp/6aaMFAl3EzRoACgkQMRa6Xp/6 aaNJeg//SIPuvN0t9CaOVRrQpGS2qojj+VfZwXDLHIt0SAyaYBKPyykAwY5SZ9oG PqIMctCJJa9YXTPiQoSvUMvR8IibvR4tuWs4V9rsfEvk9PmSmI6EJLmnjHIB9ISM CPGanMx/77Xep6ApCRHh3yoVWqGdExYZ06Cv9myr6pW9tMlrSS4yaaFaxLHjTCCo PjSioYxrHutN2T3iNZFf7yTkJtLvk0JHl7Y+qJtwxej2vbI8azz16c6lhTPQFVeB gHedHYhJnJzCGpyJvS3AxVlIjbeNoHFeRE63TTC2gcdUkHhBWXB4uGxPfyuAcJk3 QkwnKUyUe7WdeKQ4mvtNbPYdm8beN/DiwCPIvX8dbGWE+dYahsvFOUcGwxyu3Tkj w1K2Nw5aSHW1bpfbhbQ9DyqYty5X8o2nI7MTac9jMOM5NKcgUPhmY4VERMkxHAdg 7vR9Tk+N2ghXCTMSIV31qHrOd3mY48Wr+1Z0R8WAQggAaUxNhRPWWXZ3vq8QfCRA 6vLeFPBMfxlXNTmhBvyYBO7V6Pt1cuUUualBXGoZZ1PlgDwT1gS3wrUliLc9AS07 VEYTosNGg7kCdrg9qX+iwCual4zWTJqjNsXQ+c0dNGNmAG+FtDJey18afgqRxA5k Se9lWjTzCTEJ8V/8HS8iYdvz4qJHp0yEpWbWNL5+VQ3RfEm3OkM= =OVjX -END PGP SIGNATURE-
Re: Facilitating external repositories
On Mon, Nov 4, 2019 at 4:44 PM Ansgar wrote: > I would recommend against doing this as long as sources.list is a > configuration file: it would need regular updates to change to the new > signing key. That doesn't work out of the box. No updates are needed if you use what Timo suggested: > I just changed my /etc/apt/sources.list.d/debian.sources to have: > Signed-By: /usr/share/keyrings/debian-archive-keyring.gpg -- bye, pabs https://wiki.debian.org/PaulWise
Re: Facilitating external repositories
On Mon, Nov 4, 2019 at 4:52 AM Guillem Jover wrote: > The official archive-keyring packages that use these, I think it's mostly > for backwards compatibility reasons. I wonder if it is feasible to and how the debian-archive-keyring could migrate from /etc/apt/trusted.gpg.d/ to /usr/share/keyrings/ + signed-by. Right now it ships keyrings in both places. -- bye, pabs https://wiki.debian.org/PaulWise
Re: BITS from the DPL For September/October 2019
On Sat, Nov 2, 2019 at 7:06 AM Bernd Zeimetz wrote: > That leads to the question how long it takes until these bugs are being > noticed. > > I am definitely not going to test init scripts properly when the systemd > units are exactly doing what they are supposed to. The number of people > not using systemd are probably low enough to ensure bugs are not found > until its to late. It seems like autopkgtests might be the right answer here, but I don't know if debci also runs the tests on sysvinit/etc based systems. -- bye, pabs https://wiki.debian.org/PaulWise
Re: should all bug reports be filed against /source/ packages?
On Wed, Oct 23, 2019 at 2:32 PM Ansgar wrote: > It gets confused if a source & binary package with the same name, but > otherwise unrelated exist; or when the same binary is built from > different sources on different architectures; or when binary and source > versions don't match (version tracking really should use source > versions). In addition there are issues when binary packages get > renamed (e.g. when libfoo1 gets dropped in favor of libfoo2). These seem like deficiencies in debbugs that should get solved by adding fixes and features there and in reportbug. -- bye, pabs https://wiki.debian.org/PaulWise
Re: Debian and our frenemies of containers and userland repos
On Mon, 2019-10-21 at 18:58 +0200, Enrico Weigelt wrote: > I'm pretty sure it does exist, since I wrote it :p > > https://github.com/metux/docker-buildpackage I couldn't find it in Debian so I incorrectly assumed, sorry. In case you want to get it into Debian: https://mentors.debian.net/intro-maintainers -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Accepted libapache-mod-auth-kerb 5.4-2.4 (source) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Mon, 21 Oct 2019 11:15:20 +0800 Source: libapache-mod-auth-kerb Architecture: source Version: 5.4-2.4 Distribution: unstable Urgency: medium Maintainer: Ghe Rivero Changed-By: Paul Wise Closes: 934043 Changes: libapache-mod-auth-kerb (5.4-2.4) unstable; urgency=medium . * Non-maintainer upload. * Apply patch from upstream issue tracker to fix crash (Closes: #934043) Checksums-Sha1: 7b3723f8f82f95dd2e537d2467477df7c961a134 1849 libapache-mod-auth-kerb_5.4-2.4.dsc da1c7affa7dac60fe0c2b73a8828a96b0f6ba828 51186 libapache-mod-auth-kerb_5.4-2.4.diff.gz Checksums-Sha256: 4e523b4c2cfe2f26de5632e5d21c352a05da0cfa5aa595fec6463087ccc30f72 1849 libapache-mod-auth-kerb_5.4-2.4.dsc 3ce8109d98d7f8c42bfd1a98ec0ff356c50697f64c454f53bc48002075fb7f0d 51186 libapache-mod-auth-kerb_5.4-2.4.diff.gz Files: 8812316d5029c3e18ba8252c783b0941 1849 net optional libapache-mod-auth-kerb_5.4-2.4.dsc 1f7027a166038100f81ee1465096c663 51186 net optional libapache-mod-auth-kerb_5.4-2.4.diff.gz -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEYQsotVz8/kXqG1Y7MRa6Xp/6aaMFAl2tI5QACgkQMRa6Xp/6 aaOgFw/7BlSkWFZGxV1hgMbaSz//DdfLaR+wcGgFoG0/Psyx8i1b+1Wp5lWrl6Rw zLdHdSD96emHsnGRZaycL0GdvRw+Szk50tlpcGZaoepP9W1Wx2ERj3e4xljrSURs eOPu4/z1oIV8/o5GLDrr8nafBdjTnQGVc1GIsbX3IjCSc7UUD1n/FGxYD7KNA6nE qc09duQndJCJqiVtcbx4QwZ/+jLKljCiT2K3c2HxVPrSFWM8faUL0dhCiwX8fa2B VeAVlm/UfM2En39h3fAhftk32mSN5y5xjpalHYeLNR4f/yQcLROFAoIoop/CAV9g CyVE7cske70lR4kXpqk9OHDQW1odSziW566+FZcZivA3E5du2yQA/PXSdM6EOXpS uIQIW2vgaO5TgVHMTqApWOvRRfpyMEN4tcvmY+lHaTJV7F7MOc+BemVmQ+UPhahx gUhU98eQ3HdhdToowZsIfoym9X9Xb8XTL3Ckmli/6Nh+SamNeWFjcVw29kK85G+F yHdV+bn8nOToeYd2AvE4cfXu/1j7vMPTgniW/LGK4qJYldOYbknXXOKCNzs9HzuW 1D+VYuk7bYIdDmJYaiV/XYmxa+yDO8vBkwc9lB+3gOT7KdX/qi7JkhxzNk0pYV3F 7H7Em/snxCyevKSstW/DJHSg2glVkRUx/LU0cBQmBA4vfB5QplY= =uyiz -END PGP SIGNATURE-
Re: Debian and our frenemies of containers and userland repos
On Mon, 2019-10-07 at 11:29 +0100, Simon McVittie wrote: > I think "re-bootstrap, don't upgrade" is an equally good principle for > autopkgtest and sbuild? Both will be equally susceptible to accumulating > cruft during upgrades that wouldn't have been there in a fresh debootstrap, > which is undesired if you want the invariant that you are (building|testing) > in "today's" minimal environment. debootstrap uses a fair bit more time and resources than apt upgrade, so I think that both are needed. I don't want to be rebuilding sbuild/pbuilder chroots before each package build, but an apt update and upgrade before each build starts installing build-dependencies is reasonable. At work we upgrade build containers interactively if needed, upgrade them automatically daily and rebuild them from scratch weekly, this feels like a reasonable compromise to me. -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Accepted purple-discord 0.9.2019.10.05.git.862f925-1 (source) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Mon, 07 Oct 2019 14:30:00 +0800 Source: purple-discord Architecture: source Version: 0.9.2019.10.05.git.862f925-1 Distribution: unstable Urgency: medium Maintainer: Paul Wise Changed-By: Paul Wise Changes: purple-discord (0.9.2019.10.05.git.862f925-1) unstable; urgency=medium . * New upstream snapshot * Bump Standards-Version, no changes needed Checksums-Sha1: 82e8381e0fcbb16c27471b9051edec5d7266d823 1999 purple-discord_0.9.2019.10.05.git.862f925-1.dsc b6b6ad255c2ff8c4e529f2b9cd902b8f45c17e55 70231 purple-discord_0.9.2019.10.05.git.862f925.orig.tar.gz 3f0ef2a25818389f3739c30b3685f4f9a665d2f6 2584 purple-discord_0.9.2019.10.05.git.862f925-1.debian.tar.xz Checksums-Sha256: de30b9031316cca95fad6eb1abc49cac7819671dd58af19c981e323a265a5b51 1999 purple-discord_0.9.2019.10.05.git.862f925-1.dsc 9aca3823325a98a0d3fc1fa77e77b1abf6e5831fd276d9c0d6be62ae82a6b09c 70231 purple-discord_0.9.2019.10.05.git.862f925.orig.tar.gz 8f56d126bb6d0a3d01e11abce1c32092dd9e860da5fd394bcd9203588cff6bae 2584 purple-discord_0.9.2019.10.05.git.862f925-1.debian.tar.xz Files: 847a21df77b508568211f4e50e092415 1999 net optional purple-discord_0.9.2019.10.05.git.862f925-1.dsc 922929e9503d623cda7a42a6bb3915d9 70231 net optional purple-discord_0.9.2019.10.05.git.862f925.orig.tar.gz a9fe7972a8d07b6bef43935fe99b2748 2584 net optional purple-discord_0.9.2019.10.05.git.862f925-1.debian.tar.xz -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEYQsotVz8/kXqG1Y7MRa6Xp/6aaMFAl2a3OcACgkQMRa6Xp/6 aaO01w/8DYA20HPK0Fpyw9oOjpxnlV138gXG/87sA7gmddB7X92Ipemyw78oTJZf 78MupXae/MObASSkn5t2B/ya8J4zoe5GBX7qw1liff4wBGnYAFQGQuyzJeWhJNqe MzZsxq906uBBA1k1v9uOrTXl0kzcEUPwSFNTtXG8gCVXFLiOgG4mVgTCiYIrbVnj GGDWbTLJRnOfsHcUtvAbbsBr03mNoUQrGp5mzPiQ3hQdsxHpWSAzj+X7FDfSIHDj voNW6sp3G++bqpwGT+vL8Fa7w5Kce0+DshHxRQWb5Ay2tufcRm7p8idLPbFoO2tL sn5mCBSyc4+OCd2zLy/h8RgxmL2d9TajuLrd/cligC2YwRrJNcN1TvzESQ+aiXov nBS9NFLfdBUk0Dg57ZXup1vccOPh7M6PL9S9bRZEbSnNX4TKNR44cAGj5hZ5iLGa +J4zoikyIwG6jpesuu50kRr8uIPL7LsJwr9WJH4JvjX0Ut1hqduGY45PPZFeGkNY fb7IBYVBducMPZI9NPgEzWyGT8n55eRL0TmwiAcR1EkQ4UXbGqVGjzrSTgCldz6D andLzIUMypnvlP5xVrMAsRM2GRVMlKAoCmNxw/99hjeR6/+hKQhLtFg/GARUJ0aW wRo6lTv1MXdudk4R3naJ2Y8T3meTwk4KeSHRPU6JE8V9yvb4vAM= =izgm -END PGP SIGNATURE-
Re: Debian and our frenemies of containers and userland repos
On Sun, Oct 6, 2019 at 7:23 PM Simon McVittie wrote: > FYI, this is because autopkgtest has an abstraction for multiple > container/virtualization mechanisms (lxc, lxd, qemu, schroot) It seems like this abstraction should be split out of the autopkgtest source and then depended on by autopkgtest. Do any other such abstraction layers exist? -- bye, pabs https://wiki.debian.org/PaulWise
Re: Debian and our frenemies of containers and userland repos
On Fri, Oct 4, 2019 at 10:49 PM Enrico Weigelt wrote: > On 24.07.19 08:17, Marc Haber wrote: > > > Do we have a build technology that uses containers instead of chroots > > yet? > > Something like docker-buildpackage ? AFAICT, docker-buildpackage doesn't exist but whalebuilder does. For systemd-nspawn containers there is debspawn. -- bye, pabs https://wiki.debian.org/PaulWise
the verbosity of apt installation/upgrade actions
Hi all,
Since 2017 I have been using the script below (please ignore the
hackyness) to filter out messages from my apt upgrade logs (mailed via
unattended-upgrades) that are indicators of success or "normally"
happen and highlight messages that are indicators of failure or are
weird in some way that I should know about.
This script is a workaround for the fact that I don't want to waste
time reading "unpacking foo" over and over again. I could of course
just ignore all apt output but then I would miss upgrade failures,
warnings from postinsts, adequate and how-can-i-help. Even if I did
read all the output I could still miss those amongst the many "normal"
messages. I believe this also applies to many Debian users and probably
more Debian contributors.
For many years it was appropriate to do Debian updates interactively in
case of failure so warnings etc were often seen, but these days Debian
testing is almost always reliable enough to be upgraded unattended and
people doing that are likely missing some things that they could report
as bugs or fix on their systems.
Obviously the script I use is a suboptimal solution to this problem
since it means I maintain the "normalness" of each message in a central
location instead of distributing it over the packages that are
outputting each of the messages.
Does anyone agree that this is a problem worth solving?
Does it seem OK to ask maintainers to maintain "normalness" info?
Any thoughts on how to communicate "normalness" to apt/dpkg/etc?
Other thoughts?
#!/bin/sh
cat "$1" |
sed -n -e '/^Packages that were upgraded:$/{ :a' -e 'n; /^ /ba; }; p;' | \
sed -n -e '/^\[master [a-f0-9]\+\] committing changes in .etc /{ :a' -e 'n; /^
/ba; }; p;' | \
sed -n -e '/^Restarting services\.\.\.$/{ :a' -e 'n; /^ /ba; }; p;' | \
sed -n -e '/^Services being skipped:$/{ :a' -e 'n; /^ /ba; }; p;' | \
sed -n -e '/^Service restarts being deferred:$/{ :a' -e 'n; /^ /ba; }; p;' | \
sed -n -e '/^The following packages will be upgraded:$/{ :a' -e 'n; /^ /ba; };
p;' | \
sed -n -e '/^The following additional packages will be installed:$/{ :a' -e 'n;
/^ /ba; }; p;' | \
sed -n -e '/^The following NEW packages will be installed:$/{ :a' -e 'n; /^
/ba; }; p;' | \
sed -n -e '/^The following packages will be REINSTALLED:$/{ :a' -e 'n; /^ /ba;
}; p;' | \
sed -n -e '/^User sessions running outdated binaries:$/{ :a' -e 'n; /^ /ba; };
p;' | \
sed -e '/^Building format(s) --all\.$/,+1d' | \
sed -e '/^From /,/^$/d' | \
sed -e '/^ Uninstall Beginning $/,/^DKMS: uninstall
completed\.$/d' | \
sed -e '/^Pending kernel upgrade!$/,/^so you should consider rebooting\.
\[Return\]$/d' | \
sed -e '/^Restarting services possibly affected by the upgrade:$/,/^Services
restarted successfully\.$/d' | \
GREP_COLORS='mt=:sl=01;31' \
grep --color -vPC10 \
"$(printf '%s' '
^$|
^Preconfiguring packages \.\.\.|
^\(Reading database \.\.\.|
^Reading package lists\.\.\. Done$|
^Building dependency tree *$|
^Reading state information\.\.\. Done$|
^Calculating upgrade\.\.\. Done$|
^Preparing to unpack \.\.\./[^ ]+\.deb ...$|
^Unpacking [^ ]+ \([^)]+\) \.\.\.$|
^Unpacking [^ ]+ \([^)]+\) over \([^)]+\) \.\.\.$|
^Replacing files in old package [^ ]+ \([^)]+\) \.\.\.$|
^Processing triggers for [^ ]+ \([^)]+\) \.\.\.$|
^Setting up [^ ]+ \([^)]+\) \.\.\.$|
^Selecting previously unselected package .*\.$|
^Removing [^ ]+ \([^)]+\) \.\.\.$|
^Replaced by files in installed package [^ ]+ \([^)]+\) \.\.\.$|
^De-configuring [^ ]+ \([^)]+\)(, to allow removal of [^ ]+
\([^)]+\))? \.\.\.$|
^[^ ]+ is already the newest version \([^)]+\)\.$|
^\d+ upgraded, \d+ newly installed, \d+ to remove and \d+ not
upgraded\.$|
^\d+ packages upgraded, \d+ newly installed, \d+ reinstalled,
\d+ to remove and \d+ not upgraded\.$|
^Need to get [\d,]+ [kMG]?B/\d+ [kMG]?B of archives\.$|
^Need to get [\d,]+ [kMG]?B of archives\. After unpacking
[\d,]+ [kMG]?B will be used\.$|
^After this operation, [\d,]+ [kMG]?B of additional disk space
will be used\.$|
^Get: *\d+ https?://[^/]*/debian.*$|
^Fetched [\d,]+ [kMG]?B in \d+min \d+s \([\d,]+ [kMG]?B/s\).*$|
^Fetched [\d,]+ [kMG]?B in \d+s \([\d,]+ [kMG]?B/s\).*$|
^Extracting templates from packages: \d+%$|
^Leaving .diversion of .+ to .+ by [^ ]+$|
^Removing .diversion of [^ ]+ to [^ ]+ by [^ ]+$|
^Adding .diversion of [^ ]+ to [^ ]+ by [^ ]+$|
^Performing actions\.\.\.$|
^Press Return to continue, .q. followed by Return to quit\.$|
^Installing new
Re: Mozilla Firefox DoH to CloudFlare by default (for US users)?
On Sun, Sep 15, 2019 at 5:48 AM Anthony DeRobertis wrote: > On 9/13/19 7:05 AM, Simon Richter wrote: > > > > Mandatory Encrypted SNI with no fallback option -- everything else can be > > circumvented easily. > > > > This is a game that we should not play, really. It raises the cost of > > running a service on the Internet so only big players can afford to do so. > > Does it? I haven't personally deployed it yet anywhere, but when I > briefly looked into it, it appears to require adding a DNS record & some > web server config. If anything, it appears to be harder to do if you're > a big player (e.g., making sure your DNS servers always return matching > ESNI and A/ records, even when you have geo-targeted DNS — so much > easier when you only have one server.) Does anyone know if any software in Debian supports ESNI records? Looking at the RFC draft, it sounds like adding ESNI records to debian.org would basically duplicate the DANE records debian.org already has. sigh https://datatracker.ietf.org/doc/draft-ietf-tls-esni/?include_text=1 https://serverfault.com/questions/976377/how-can-i-set-up-encrypted-sni-on-my-own-servers -- bye, pabs https://wiki.debian.org/PaulWise
Re: Common configuration of Debianish build etc. tools
On Thu, Sep 12, 2019 at 3:24 AM gregor herrmann wrote: > ~/.devscripts already exists (typically) which similar variables, > maybe this could be re-used? Using ~/.devscripts means running shell and passing variables out of it, which is quite hard to get right. The devscripts config loading module got it wrong until recently, is still a bit hacky really (but there is a patch) and still needs migration of many of the scripts from their own bad config loading implementations to the config loading module. I think it would be best to avoid code (especially shell) as configuration in favour of static configuration files with dynamic overrides added via environment variables where needed. -- bye, pabs https://wiki.debian.org/PaulWise
Re: win32-loader: Dropping Win ME/98/95 support, digital signing, Windows Store
On Tue, Sep 10, 2019 at 4:18 AM Thomas Gaugler wrote: > Therefore I intend to switch win32-loader from an x86-ansi to an > x86-unicode installer. The drawback would be that Windows versions prior > Windows XP would no longer be supported. Would it be possible to build both versions in order to keep support for ancient Windows versions? > Furthermore I would like to increase user confidence and trust by > digitally signing the win32-loader executable. How could > win32-loader be enhanced with a Debian code signing certificate? We have a code signing certificate for signing our shim binaries for use with secure boot, probably a similar approach will be useful for win32-loader. https://wiki.debian.org/SecureBoot/Discussion > Last but not least I wonder if there would be any value in distributing > win32-loader via the Windows Store [2]. Sounds good to me. OTOH expanding the visibility of win32-loader could introduce significant user support load if people don't understand what the app does, download and run it, make their Windows computer be any different to normal (including introducing black BOOTMGR/NTLDR screens for eg) and then come complaining to Debian or leaving bad reviews on the Windows Store. -- bye, pabs https://wiki.debian.org/PaulWise
Re: Mozilla Firefox DoH to CloudFlare by default (for US users)?
On Mon, Sep 9, 2019 at 2:31 AM Ondřej Surý wrote: > Mozilla plans to enable DoH to CloudFlare by default to US based users Does anyone know if there is any plan for the DNS root servers to enable any of the DNS privacy options? AFAIK the available options are DNSCurve, DoT or DoH. -- bye, pabs https://wiki.debian.org/PaulWise
Accepted purple-discord 0.9.2019.08.26.git.df0d11a-1 (source) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Fri, 30 Aug 2019 09:30:58 +0800 Source: purple-discord Architecture: source Version: 0.9.2019.08.26.git.df0d11a-1 Distribution: unstable Urgency: medium Maintainer: Paul Wise Changed-By: Paul Wise Changes: purple-discord (0.9.2019.08.26.git.df0d11a-1) unstable; urgency=medium . * New upstream snapshot Checksums-Sha1: 395d1e58daf37552735796ea01141444c73261ba 1999 purple-discord_0.9.2019.08.26.git.df0d11a-1.dsc feecfa83ef5c10389b7cb448e3b183ef31422ff9 69095 purple-discord_0.9.2019.08.26.git.df0d11a.orig.tar.gz fc393da541d61369fb204001da5122bb4da5f365 2560 purple-discord_0.9.2019.08.26.git.df0d11a-1.debian.tar.xz 1e2728b81dd9919131cd9e740f72550ad7a21104 11871 purple-discord_0.9.2019.08.26.git.df0d11a-1_amd64.buildinfo Checksums-Sha256: e299d31425433f550bcda7800afa282fc76d6e7c94f370ce3aff2fcd881dbc57 1999 purple-discord_0.9.2019.08.26.git.df0d11a-1.dsc e19944272d648cea08c29c8532013c9855a0dab9911eb44c1f43c32d50726ef8 69095 purple-discord_0.9.2019.08.26.git.df0d11a.orig.tar.gz 57b864dd187c3e1a77ed69204ea4ef9afb2771f6e3654413a3cb79170f543510 2560 purple-discord_0.9.2019.08.26.git.df0d11a-1.debian.tar.xz 14718fbfc1fbdcfe9d795c23d1310d9623db0b8cf80ee672d8b5741110a82e22 11871 purple-discord_0.9.2019.08.26.git.df0d11a-1_amd64.buildinfo Files: 5e14ac2746301a76405fb96c6b778901 1999 net optional purple-discord_0.9.2019.08.26.git.df0d11a-1.dsc 8706d93e32076313bb458465f2018cc1 69095 net optional purple-discord_0.9.2019.08.26.git.df0d11a.orig.tar.gz 02b3197f61f14da43cefe728f20c9410 2560 net optional purple-discord_0.9.2019.08.26.git.df0d11a-1.debian.tar.xz 67af02c20998a7f315e853e7392ce5dc 11871 net optional purple-discord_0.9.2019.08.26.git.df0d11a-1_amd64.buildinfo -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEYQsotVz8/kXqG1Y7MRa6Xp/6aaMFAl1ogD0ACgkQMRa6Xp/6 aaObdhAAqu0jooqwxf96FZxfAeUB/CsRDe3eOos9xsnZJFr478axtYEPYYimFv31 kbsBywxWkRgGa4JLHYJ0fUigzP7HtNCMbGwVcdf7r6GZJhwx3o8zaLZQAAGzymUe n+C04g6l7oBZNqGJUqRU0Ydzf48SpeHfUnYkaX87umgjXQ94oFcXxRtCQwz4lsp9 idT4u5d0SgjLUnp4cRRoYyc06aLdjbU4jru1FsLi5EgaraC8OBUd8XwfScskEfz+ g+f+OL3gpv0ekcH2u2b3TDIciutn+7iT/BtzAEeGPWDuWRZEj3jbjiNDU/7pMiB0 Z79WMAkdEVLDtK+ERj5ZMdiz4OW/6SgOnSzKIIUV/yk0IbYsEFzBdHcVsBJNAXwt 5HVwsHEEmU8LJ+GVHGXf7yeQ72XbgROU7eN9//4q87/Yl20wFLF0PdCSdYPRiQEC RDnFcP+Hou8FfjSYCx5Eu+QFvp8z10wnXC0bInW+hGNmmUhXxi4Xa1frg3MlvY0P muoRreWqfLPsI0NQ1vwIcaJ1/QvHMBT5r93sJ1tSaDcR6mzAsVilVCF+vqbWr0zo 6WhThvgezy660+5mPXskVG0ZVXNRGDn5xnAnbb7fzBA2+2C7Oj6zY6ScnIhxBFwA n2wiiGjEvwVSJ+CLJcE13oOVKBOEGqy7BVn3w2WjPVn3eVHZq2s= =wgV1 -END PGP SIGNATURE-
Re: Git Packaging: Native source formats
On Thu, Aug 29, 2019 at 4:00 AM Sam Hartman wrote: > Using native source formats (1.0 and 3.0 (native)) is attractive for > some git workflows. It means you can just export the git repository and > don't need to make sure that you use the same upstream tarball when > upstream versions are the same. Why use the native format instead of the git format (which uses git-bundle)? -- bye, pabs https://wiki.debian.org/PaulWise
Re: Has anyone else perceived this email as spam?
On Fri, Aug 23, 2019 at 7:31 PM MAD wrote: > Has anyone else perceived this email as spam? The message you have quoted is definitely spam. -- bye, pabs https://wiki.debian.org/PaulWise
Re: lintian-brush adds redundant data
On Wed, Aug 21, 2019 at 2:48 PM Andreas Tille wrote: > DEP-12 is declared as "Work in progress" (without any progress since 5 > years) while DEP-5 is well established and decided. Charles and I > invented d/u/metadata to store publication information and it turned out > that there is other sensible information about upstream that can be > stored there as well. I'd vote against any duplication of information > in any way. So as long as Name and Contact are defined in DEP-5 it > should not be in DEP-12. These fields seem like they belong in DEP-12 more than DEP-5. -- bye, pabs https://wiki.debian.org/PaulWise
Re: ML-Policy and tesseract-ocr
On Wed, 2019-08-14 at 17:44 -0700, Mo Zhou wrote: > * For a source package that produce binary package containing ML models, > it's encouraged to write a "reproduce-original-model" that may e.g. > download a dataset from internet and redo the same procedure to > produce the original model. Sounds good except for the name. I'd prefer something more generic that can also be used in situations that don't involve ML but are still resource intensive enough that we won't run them on every build. -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Re: ML-Policy and tesseract-ocr
On Tue, Aug 13, 2019 at 8:45 AM Sam Hartman wrote: > In cases where the model is not recreated, but where software in Debian > could create the model, I think a README file is better than a package > relationship. Personally, I'd like to see Policy specify a standard mechanism that people could use to indicate to debian/rules that they want to automatically rebuild *everything* from source, not matter what the cost is. -- bye, pabs https://wiki.debian.org/PaulWise
Accepted uhubctl 2.0.0-5.1 (source) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Thu, 08 Aug 2019 14:56:30 +0800 Source: uhubctl Architecture: source Version: 2.0.0-5.1 Distribution: unstable Urgency: medium Maintainer: gustavo panizzo Changed-By: Paul Wise Closes: 925913 Changes: uhubctl (2.0.0-5.1) unstable; urgency=medium . * Non-maintainer upload. * Use full path to uhubctl binary in tests (Closes: #925913) * Mark the uhubctl -v test as superficial * Switch from redirecting stderr in script to Test-Command and allow-stderr * Use long option --version instead of -v in test Checksums-Sha1: 7958e0e30f2190403ab105b3833123d33fdeaed5 1871 uhubctl_2.0.0-5.1.dsc 202393e592c521f522cabf197f18fdccca598360 2828 uhubctl_2.0.0-5.1.debian.tar.xz Checksums-Sha256: f5b8c6bff74c7f27f0a8d2723ede15f84508f028d2d16379892202c6891e1d93 1871 uhubctl_2.0.0-5.1.dsc 65801e8857004d65d9f6bc93d17bc41b07a840494078d0e1e4c5d15c13579f91 2828 uhubctl_2.0.0-5.1.debian.tar.xz Files: 7891eaae45168367cd906303b3fdd1e8 1871 electronics optional uhubctl_2.0.0-5.1.dsc db5061ac4e0f772eefb259e96e4101ef 2828 electronics optional uhubctl_2.0.0-5.1.debian.tar.xz -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEYQsotVz8/kXqG1Y7MRa6Xp/6aaMFAl1LyOwACgkQMRa6Xp/6 aaP7TQ//chES3AYay10L3Kxfd0E5r3/7niTbfAYFokZRl+hAdy7srnPei5N0+ZZk K+bwLGPdbgJzdu++J4bg72SlqGMogdoUmujZHUloYCv5eudovcKvDHVNgoqgyYUH HWIrDL920QvbZLUpylXp9SMUiAwfYQK5Ca+vCZLSV/m46A9n1XP3Uy9vMfEmXMBc Bg7aUPEdAGt6M7UL5OrVTGshvOT73ycC7UM1+ZxfsU6hUGNIt0HWNr8KWKbkmkmT M8hsyeOUKbaMUPvhiTwYrZqFEc6/RJJ76N0mD3huuOjCagPaXVPJmHINoDZtNXO8 UF7puHDrbqkx5uQX41VJtlVOS0f+KnixG0dqtVelsB5hZB3Y9w1sCG+zW/GjFGmV Ckhu3SoegGAw3d1qNsT1FPQeUmoQeWlsmBSX/33RgA8DQL8kjONDYgyoeo18XidH 3LRYHJZ4Ip4BIwS8iVy4FBQ4xColmQLAFVlxtZOegxPUFBMBiBFkXfgG6knYNwgu fKdBF8G1sjji+h7S8eKwFxkN2Yyj95c6xIlbi80MhqBGUEs4Ggc15hT9q4+Ms4ek bTu1A/nP5Wn0QlUTL0FfGwBmjRrotDQFOhtVXYyzAiRBuHh45w0t/OxwcKMCd2y7 0o0zPwF99VtcRXk/CEZPE5r5puR9ctDjFskfsV4WZtFB7MJq1WY= =biVx -END PGP SIGNATURE-
Re: Generating new IDs for cloning (was Re: duplicate popularity-contest ID)
On Thu, Aug 8, 2019 at 4:59 AM Andrei POPESCU wrote: > 1. Delete the contents of /etc (all of it) > 2. If a package doesn't find its "stuff" in /etc it regenerates it from > defaults. There is still way too much stuff that defaults to installing important files in /etc (default config settings, init scripts etc). It would be nice to have a way to tell all postinsts to not generate system-specific files (like machine-id or SSH keys) but do generate caches. Cleaning up after postinsts seems like a hack to me. There are some notes on reproducible installs here, IIRC Tails and Webconverger have achieved that for their live images: https://wiki.debian.org/ReproducibleInstalls -- bye, pabs https://wiki.debian.org/PaulWise
Re: duplicate popularity-contest ID
On Tue, Aug 6, 2019 at 7:34 PM Bill Allombert wrote: > A related issue is that the submission time is randomized, but if > 2600 systems have identical /etc/cron.d/popularity-contest files, they > will report at the same time, causing network spikes. BTW, a systemd service timer has native randomisation with RandomizedDelaySec/AccuracySec so adding one that shadows the cron job and disabling the cron job on systemd systems could provide more load spread because each system would send the data at a completely different time each day. The apt package is a good example of how to do this (except for the randomisation part). -- bye, pabs https://wiki.debian.org/PaulWise
Accepted purple-discord 0.9.2019.07.29.git.763ba75-1 (source) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Fri, 02 Aug 2019 13:57:30 +0800 Source: purple-discord Architecture: source Version: 0.9.2019.07.29.git.763ba75-1 Distribution: unstable Urgency: medium Maintainer: Paul Wise Changed-By: Paul Wise Changes: purple-discord (0.9.2019.07.29.git.763ba75-1) unstable; urgency=medium . * New upstream snapshot Checksums-Sha1: b07bb8c8c2efeb738b383802a2cfc74ea100f0e8 1999 purple-discord_0.9.2019.07.29.git.763ba75-1.dsc 2fa642eca0b61307f25154433906700d748e911e 65710 purple-discord_0.9.2019.07.29.git.763ba75.orig.tar.gz eff7934f3b411d31a0c28f28b364fe1e3f76c481 2544 purple-discord_0.9.2019.07.29.git.763ba75-1.debian.tar.xz Checksums-Sha256: 7b259b6dfbee1ded3680018397dd86a10f7d60c9f9d06d8f28762ae1e4a72ca6 1999 purple-discord_0.9.2019.07.29.git.763ba75-1.dsc c68ede9d28e8f3782af9752ad08686663e5c2217b11a86010849761b21b29d8d 65710 purple-discord_0.9.2019.07.29.git.763ba75.orig.tar.gz c4f4287a3af08ce7fa3428c8be5a8723efcb845381874632da8824fa21d4afbc 2544 purple-discord_0.9.2019.07.29.git.763ba75-1.debian.tar.xz Files: 62cb06d7d0942085ddeac5158c026c20 1999 net optional purple-discord_0.9.2019.07.29.git.763ba75-1.dsc 4e9a668954b8bb1e271b3fb9e2b8129c 65710 net optional purple-discord_0.9.2019.07.29.git.763ba75.orig.tar.gz a1817da7ae37c78c3d678759731780f5 2544 net optional purple-discord_0.9.2019.07.29.git.763ba75-1.debian.tar.xz -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEYQsotVz8/kXqG1Y7MRa6Xp/6aaMFAl1D0OcACgkQMRa6Xp/6 aaNugQ//Zimcvgk6ql7kelBovi0Yln7dib02JNJu1iR2XNqcR2VBDvkav5AXPmZs VukHKit9qUAdtZnxh6OJzZ+G0fsoT0S88n0O85VkaueSZ5JjuygKsOnr/r1P9hZv vNS1g9iRGOtWdZoUCaWtrK65G1cuHkDQsE+RMT6o45cLHsDJPh3k5NTWUMuTQ6iP IDBRSmf/AWR/21H1wL0AlbSZasIVW2WQt8E3rtBLflJd5rGn4FsPYdNtmOLVW6ps GB8ivJNtfwxMFhZZg66Yx8rtfiHpD3exsq2ERj28Bd1bQJdPYs6Ypw9Ci1+RIOkK L2c2i3g5so529XSzp7g++Ts0ZIvKbRPYoMmGcyhCCA3YOR/LAkkr8MFWaGHcO7bb 4yN7gDf6OesM15FVS40bU+lYLUiWZPXM3rCBxkPzkYUckGF3iPoZUJ3wVQWxVWSg we7PU1lmJAuobv/1wWi9wcelcUzRezCOciSXoEMmVGBZlJicbjcDlucP6+SqWBVY yFoZvy3TGEdhT7f6rVDGluvNj0vOLEZha6H7H8nHrg2veA+DtGPQBH8Xfz/Ld85o a37hnDjY7HlFSNPRp6xLqFKUyR0glRaR60pXEsJbCWLk+6E5UKstjtct3u1CuQug u6XWZnkEwT8+lE55dFuNE1anehYwxUkBbhz4nRL/QlOfnz5I3gw= =z4eT -END PGP SIGNATURE-
Re: unsigned repositories
On Mon, Jul 29, 2019 at 3:02 PM Simon McVittie wrote: > > On Mon, 29 Jul 2019 at 00:17:17 +, Thorsten Glaser wrote: > > echo "deb [trusted=yes] file://$base ./" > > >"/etc/apt/sources.list.d/$this.list" > > sbuild and autopkgtest (and probably other build/CI tools) also rely on > being able to inject local packages into a build/test environment using a > [trusted=yes] apt repository. The local-apt-repository package also uses [trusted=yes] in a sources.list.d file. -- bye, pabs https://wiki.debian.org/PaulWise
Re: B-D on src package? (was: Re: Challenge from Julia's non-standard vendored openblas"64_"
On Sun, Jul 28, 2019 at 10:33 PM Johannes Schauer wrote: > If we choose the "src:" prefix to pick source instead of binary packages, then > it's important that we don't have any binary packages called "src" and no > source packages with a name equal to a valid debian architecture. Could we have a double suffix instead to avoid these issues? Build-Depends: foo:src:src -> src:foo unpacked in /usr/src/foo Build-Depends: foo:src -> b-d of src:foo for the current host architecture Build-Depends: foo:src:amd64-> b-d of src:foo for amd64 Build-Depends: foo:src:native -> b-d of src:foo for the current build architecture -- bye, pabs https://wiki.debian.org/PaulWise
Re: B-D on src package? (was: Re: Challenge from Julia's non-standard vendored openblas"64_"
On Sun, Jul 28, 2019 at 10:04 PM Mo Zhou wrote: > Is such demand common enough among developers? There are several ways this would be useful: To replace all librust-*-dev and golang-*-dev packages (they contain source code). To replace all toolchain -source packages, so that cross-compiling toolchains can be built from separate source packages. To replace all out-of-tree Linux kernel module -source packages, so that dkms/etc doesn't need a binary package duplicating the source. Anywhere you want to build multiple independent build configurations of the same source code in different ways. -- bye, pabs https://wiki.debian.org/PaulWise
Accepted apt-xapian-index 0.50 (source) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Sat, 27 Jul 2019 19:01:18 +0800 Source: apt-xapian-index Architecture: source Version: 0.50 Distribution: unstable Urgency: medium Maintainer: Debian QA Group Changed-By: Paul Wise Closes: 758403 804099 841417 Changes: apt-xapian-index (0.50) unstable; urgency=medium . * QA upload. . [ Barry Warsaw ] * Switch to Python 3 as the default. (Closes: #804099) * d/compat: Bump to version 9. * d/control: - Bump debhelper version to >= 9. - Switch dependencies to their Python 3 version. - Use X-Python3-Version instead. * d/rules: - Fix the dh argument order. - Use --with=python3 and --build-system=pybuild - Run the tests in an override_dh_auto_test target. . [ Paul Wise ] * Use the right path to the GPLv2 in Debian * Migrate a few minor things to Python 2 only * Use dpkg-source format 3.0 (native) * Use the current version of python3-xapian * Correctly import from the Python 3 configparser module * Decode bytes from Xapian to Python 3 strings * Update VCS information to use the new Salsa repo * Switch from debian/compat to debhelper-compat * Bump debhelper compat level to 12 * Drop ancient X-Python3-Version * Fix spelling errors . [ Elena Grandi ] * Don't traceback on missing index. Closes: #758403 . [ Ralf Treinen ] * Fix typo in postrm (Closes: #841417) Checksums-Sha1: cf68281fdfdaf145d840f12e127463ee62ed863a 1804 apt-xapian-index_0.50.dsc 15b35c8459a49d3dcde57d675b1fadbf49ac318c 44792 apt-xapian-index_0.50.tar.xz Checksums-Sha256: 07c68969cc85eaff2f7fc4394aaf55d30b2dd76c7762ca3cb999ce9083679ce9 1804 apt-xapian-index_0.50.dsc 090d0de29cb1fdeb964cac5f77960b3a2b462ebef6ce70cfe5655d41f3329e6a 44792 apt-xapian-index_0.50.tar.xz Files: cf01ddfe31b56df24a34007686da0d2c 1804 admin optional apt-xapian-index_0.50.dsc e55c496575a3b6bf7b43598c3769145d 44792 admin optional apt-xapian-index_0.50.tar.xz -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEYQsotVz8/kXqG1Y7MRa6Xp/6aaMFAl08MZUACgkQMRa6Xp/6 aaPNXw//ZU703KhIO58Oh4cP/iTV52nJAb1Hlq8JGJaagiS8bKFbg4ZytVa+thcw MLCxTjD3DvOcnQ4ZL/ArzdWh4Ob/ZcU2yi4x8nCS5AUj4AkPBIu5l252Q5xQKfJJ kjHa0B9zl9/9OduciuTnuEa0iH1T3h4wSxAZLUVmNdxucOXI59K5MRzbGnkCwLku ayFf3KO/+pYwBBB1DCsnwYkvJ6eVczEH70PyJNqnsop2SyVEoujZpmCKkLP40+5t YatAj69B6kZpzoR7vGGsReyBMXsYMNUwB4AzZM6CCpxKDoDBB69abm+OCCJtivt1 d/WPiy4i25t2MEbObX3Cyj8ca8432LG8tNrxqSX0Pi9cJbfwvY+GnAYS1EmYECpa jLLF0aQM4/az6tZQWTmetyCSGui1N6rTjDQDhQxOTxT8gL1JbwUFp7dl8/o1XfrA QUI9F2f6/FJSlYLZdgpIHtBGlJZPZ8NCdzrFTF+DF6ftN/MmPCoOJvMGBCUvURfQ W071GZjr5MOmwQVLxWQHN0X+roI7jgoFySLXfSzHyX6MFzOFf7ayXopCd5aQDDwv CL+lkGGVNVbC58SPSbG2CPYxe/qRLh9d8FkKpMF3FZ3UBcb6Vf3i4AIogHOq2AME FOZ4bgSPhVyyeLO0SYkPmY5Jkp7SzBi2BrS0J5Zg4y9WFSxpWDw= =6vQV -END PGP SIGNATURE-
Re: regarding non-free firmware for wi-fi and ethernet
On Thu, Jul 25, 2019 at 3:03 PM Abibula Aygun wrote: > It is ok to insert in Academix GNU/Linux installation media the non free > firmwares? This depends on what is allowed by the licenses of the non-free firmware files. I expect most of them allow redistribution though, especially since Debian is redistributing them. Reading the licenses is the only way to know for sure though. > Anyway, the non-free firmwares are used by the installer an not by final > installed system. Most non-free firmware needed by the installer are also needed by the final installed system. -- bye, pabs https://wiki.debian.org/PaulWise
Re: Debian and our frenemies of containers and userland repos
On Thu, Jul 25, 2019 at 2:18 PM Johannes Schauer wrote: > But you'd have to ask somebody who is more knowledgable about the security > implications of such a change. There certainly is a reason why #898446 is > still > open. > > Furthermore, since buildds currently use the schroot backend, I guess that > buildd admins already took all necessary precautions to secure their systems > against arbitrary code running as part of the package build process. I do not > know what benefit the "unshare" backend would have for buildds. I think my mental model of what the "unshare" backend does was incorrect. I didn't think it needed #898446 to be closed. I assumed it was just like schroot except with the addition of moving all processes run within the chroot into a separate network/process/mount/etc namespace with no access to the host namespaces. The primary advantage of this would be to isolate the build chroot from the network. Perhaps schroot is the component that should be adding support for separate network/process/mount/etc namespaces? -- bye, pabs https://wiki.debian.org/PaulWise
Re: Debian and our frenemies of containers and userland repos
On Wed, Jul 24, 2019 at 2:42 PM Johannes Schauer wrote: > Or using the built-in "unshare" backend which uses linux user namespaces: > > $ sbuild --chroot-mode=unshare --chroot=debian-unstable.tar Do you think it is feasible to use this on some of or the majority of Debian buildds (most run stretch right now)? There would need to be exceptions but most packages should build correctly in this scenario. The main exception would be the Debian installer, IIRC it needs network to the local apt mirror during the build process. -- bye, pabs https://wiki.debian.org/PaulWise
Re: xTuple Postbooks license change
On Thu, Jul 18, 2019 at 1:12 AM Seth McClain wrote: > xTuple recently took most of their git repos off of github and is > changing the license to much of the code moving forward. > > https://xtuple.com/blog/ned/free-software > > Debian currently offers builds of Postbooks. > > https://salsa.debian.org/xtuple-maintainers-team I'd encourage you to file a bug against the postbooks package to discuss this with the Debian xTuple maintainers team. > It would be a shame for the FOSS community to lose this CPAL licensed > software. > > Which directions might the Debian community take regarding Postbooks? When Redis changed the license of some modules recently, the Debian and Fedora package maintainers forked the affected modules from the commits prior to the license changes under a new organisation called GoodFORM. Since Postbooks is distributed in Debian (and derivatives) as well as Fedora/EPEL, the same process could be done for Postbooks. https://goodformcode.com/ https://repology.org/project/postbooks/packages -- bye, pabs https://wiki.debian.org/PaulWise
Re: default firewall utility changes for Debian 11 bullseye
On Wed, Jul 17, 2019 at 7:05 PM Helmut Grohne wrote: > If you want to make firewalld the desktop default To me, something like opensnitch seems like a better option for a desktop firewall once it becomes more mature and enters Debian. https://github.com/evilsocket/opensnitch/ https://bugs.debian.org/909567 -- bye, pabs https://wiki.debian.org/PaulWise
Re: Debian distribution
On Tue, Jul 16, 2019 at 7:00 PM Javeed Ahmed wrote: > can i make my own os using debian as a base and distribute it? Yes, but you can also join the Debian project and help us improve the Debian operating system for your use-cases. Would you like to share your plans for how you want to change the Debian operating system? If you would like to add new packages, check out this page: https://mentors.debian.net/intro-maintainers Other ways to contribute to Debian are documented here: https://www.debian.org/intro/help -- bye, pabs https://wiki.debian.org/PaulWise
Re: systemd services that are not equivalent to LSB init scripts
On Mon, Jul 15, 2019 at 6:48 PM Simon Richter wrote: > The main limitation seems to be that it's not permitted to modify > inetd.conf from maintainer scripts. We could probably "fix" this by adding > an "inetd.conf.d" mechanism. There is update-inetd, but it doesn't support xinetd and doesn't appear to have debhelper integration. -- bye, pabs https://wiki.debian.org/PaulWise
Re: Proposition: Insert Mozilla Firefox Release in Debian
On Sun, Jul 14, 2019 at 9:57 PM wrote: > Please Insert Mozilla Firefox Release in Debian. Mozilla Firefox is available in Debian, the package name is firefox-esr. -- bye, pabs https://wiki.debian.org/PaulWise
Re: Search field in LXDE Desktop
On Sun, Jul 14, 2019 at 9:51 PM wrote: > Please add a Search field in LXDE Menu. This suggestion sounds like it would be best to send to the LXDE community: https://lxde.org/ -- bye, pabs https://wiki.debian.org/PaulWise
Re: Is there system-config-lvm for Debian 10?
On Sat, Jul 13, 2019 at 5:27 AM Joe Irungu wrote: > Thus is there a system-config-lvm for Debian 10 or how else can I manage logical volumes in Buster? system-config-lvm was removed from Debian buster in 2017: https://tracker.debian.org/pkg/system-config-lvm https://tracker.debian.org/news/851840/removed-1118-3-from-unstable/ https://bugs.debian.org/865977 If you would like to reinstall system-config-lvm, you will have to add Debian 9 stretch to your apt sources.list and install it from there. Please note that it is unsupported though. The removal bug report suggests kvpm as an alternative, but that isn't in Debian any more either: https://tracker.debian.org/pkg/kvpm https://tracker.debian.org/news/1012759/removed-0910-11-from-unstable/ https://bugs.debian.org/916802 https://bugs.debian.org/915690 https://bugzilla.redhat.com/1489590 The partitionmanager package seems to be a more modern KDE equivalent of that though. Other options might include gnome-disk-utility or gparted, depending on your needs. https://www.centos.org/forums/viewtopic.php?t=48120 https://askubuntu.com/questions/968297/is-there-a-new-gui-for-lvm -- bye, pabs https://wiki.debian.org/PaulWise
Bug#931290: general: Asrock A300 Deskmini AMD Athlon 200GE ends in black screen Monitor has no Signal
On Sat, Jul 13, 2019 at 1:21 AM Joe Lobeck wrote: > in the meantime I found that the most things work form kernel 5.0 or higher. > Unfortunately so I will have to choose an other linux distribution as such a > kernel > is for debian only from the experimantal repository avaiable. > If you have any other idea how to make debian stable or testing run with this > hardware please let me know. There are several options, you could do them in parallel: You could install the experimental Linux image package on stable. At some point a newer version of Linux will enter unstable, then testing and then stable-backports, you could switch to testing or use stable+backports. You could bisect the Linux kernel commits to find out which exact commit fixed the problem, work on getting the patch backported to the upstream -stable versions of the Linux kernel and then wait for a Debian point release to include the latest -stable version of the Linux kernel. https://wiki.debian.org/DebianKernel/GitBisect https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html -- bye, pabs https://wiki.debian.org/PaulWise
Accepted foxtrotgps 1.2.2-1 (source) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Thu, 11 Jul 2019 11:52:27 +0800 Source: foxtrotgps Architecture: source Version: 1.2.2-1 Distribution: unstable Urgency: medium Maintainer: Paul Wise Changed-By: Paul Wise Closes: 926575 Changes: foxtrotgps (1.2.2-1) unstable; urgency=medium . * New upstream release - Fixes building with libgps 3.18 (Closes: #926575) * Switch from debian/compat to debhelper-compat * Bump debhelper compat level to 12 * Add Rules-Requires-Root: no * Bump Standards-Version * Remove Timo from Uploaders, not active on foxtrotgps * Enable bindnow hardening flag * Add python3-bs4 alternative to python3-beautifulsoup Checksums-Sha1: 2ebc9c0403d0265de4b3815c6b19e0e6adc4e7bb 2170 foxtrotgps_1.2.2-1.dsc a72c2a3b2cf2e25a3619168c6961b3f7f424f58b 1692120 foxtrotgps_1.2.2.orig.tar.xz 55cbd5b0b053439869eaa6196f6273aefa73eb20 866 foxtrotgps_1.2.2.orig.tar.xz.asc 5854bb3e500598dcdd1fe00bf8073c567de4f61e 17192 foxtrotgps_1.2.2-1.debian.tar.xz Checksums-Sha256: cf4b141e10d5df77e33a7a6dd9bb4185bee985296f6af0785b9eff681f100754 2170 foxtrotgps_1.2.2-1.dsc 6fe6ed5c33b2f61cbff13c524c55ed600c85c5d80e85de9b4182f1596419363f 1692120 foxtrotgps_1.2.2.orig.tar.xz f6a44b5c881f50b9fafa4e31f5c0a95b8cbf387bbb34df0895dd807f36ae716f 866 foxtrotgps_1.2.2.orig.tar.xz.asc eb24241cf784e5e49e8a1dfcf661ec080f9503989b37dfae62a8867602a4f062 17192 foxtrotgps_1.2.2-1.debian.tar.xz Files: 74686fe24b2847a5b2267232b67d3f74 2170 comm optional foxtrotgps_1.2.2-1.dsc 3a7e7b94202134b51b11dcb80734eb7f 1692120 comm optional foxtrotgps_1.2.2.orig.tar.xz 4a5f18934ad8c8dae41b1d4403e89b95 866 comm optional foxtrotgps_1.2.2.orig.tar.xz.asc 04d4c5bd9b27a1f41cc5b8001d2c27c7 17192 comm optional foxtrotgps_1.2.2-1.debian.tar.xz -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEYQsotVz8/kXqG1Y7MRa6Xp/6aaMFAl0ms18ACgkQMRa6Xp/6 aaMoIA/+KVDU7BL/fcOlOnpiNMVc2XZ4PYUESYzgEM3vIGY2BxHNL/h6IT8LU6PP KNdA42oehuGsRL82qYtmZauEgkCqY9DIFcbolDK1RVNOmxi7KfcjHz86nnYsvdX6 juCrXQsx/OnhZyluvSFgfa1vX3rYGb2I1/8PNmCun8jUohC0/f+3csqTBdY0a0rf HcOCbN7NvZG4aLzqQkdxiqhSdFBYtMpbJGC8cU9jaH5cwKKLFGc2PNDVJjZH0X+o f+dsVUaPDxuB5rcxWqFqtsWjjU9tfg7hIkDjRUVDruRUqJfK11umpjZxluLvDEOW 5niym4BlGsa2RoCI2BuIw2j4DE04Ke2b1JTb11TDPE+t4eZ0WmC/XyR+olxcMBxF deGCSIW//DN58Yx6t9iWMaQIGdl/U3Ybn4D2AfU+2unyE675eRiWEKVpUn1wRZ0k fBkzuzYH47FCw/aeIgR8eJce689uTec91x6L52cLAPGezR0PLqfJCPSwSb4g9yVq 1dv6dDKLZpkiEX36jwY6fA1MhSRyHEVdGu1L2SmuZ704Zd9LPXBb050E3+RnN6y1 0/RmYxrkR+VHvaCMCc3XwXNXhSWtkLKU36iB8K2nLdizSUKuX5d/P8d/IjF+wjkV Z1N1fc+MmnZ3truNbIV+ORqsk3GaCTXj6DzK17/o+Mesfs+F5co= =s5KU -END PGP SIGNATURE-
Re: Apt-secure and upgrading to bullseye
On Wed, Jul 10, 2019 at 7:59 PM Julian Gilbey wrote: > So I read apt-secure(8), which gives no indication of how to "accept > this explicitly", and neither do any of the linked wiki pages. > > Any suggestions? There are two options: # apt update # apt-get --allow-releaseinfo-change update -- bye, pabs https://wiki.debian.org/PaulWise https://bonedaddy.net/pabs3/
Re: Dropping Release and Release.gpg support from APT
On Wed, Jul 10, 2019 at 4:18 PM Julian Andres Klode wrote: > What's the use case for having oldstable in your sources.list on > unstable/testing machines? I have it in a chdist so that I can look up package versions in old releases. -- bye, pabs https://wiki.debian.org/PaulWise
Re: Uninformative hyperlink in O: (package orphaning) bug reports
On Tue, Jul 9, 2019 at 11:24 PM Nicholas D Steeves wrote: > To be fair, doesn't the QA team (and random acts of kindness) often > keep these packages alive? There is no specific team maintaining orphaned packages, other than the set of Debian contributors who are motivated to do that. -- bye, pabs https://wiki.debian.org/PaulWise
Re: Dropping Release and Release.gpg support from APT
On Wed, Jul 10, 2019 at 2:53 AM Julian Andres Klode wrote:
> Timeline suggestion
> ---
> now add a warning to apt 1.9.x for repositories w/o InRelease, but
> Release{,.gpg}
> Aug/Sep turn the warning into an error, overridable with an option (?)
> Q1 2020 remove the code
I think this timeline is missing a few items:
File bugs/patches on dak, launchpad, reprepro and other repository
creation tools to drop producing Release{,.gpg} (including all the
ones used by derivatives and by prominent external apt repositories
and apt repository services).
Wait for all of those to be fixed.
Add the warnings.
Wait one Debian release cycle.
Change the warnings to errors.
Wait a bit more.
Remove the code.
--
bye,
pabs
https://wiki.debian.org/PaulWise
Accepted harmony 0.6.0-1 (source) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Tue, 09 Jul 2019 15:58:49 +0800 Source: harmony Architecture: source Version: 0.6.0-1 Distribution: unstable Urgency: medium Maintainer: Paul Wise Changed-By: Paul Wise Changes: harmony (0.6.0-1) unstable; urgency=medium . * New upstream release - Drop encoding patch, merged upstream - Update copyright information * Switch from debian/compat to debhelper-compat * Bump debhelper compat level to 12 * Bump Standards-Version to 4.4.0, no changes needed * Add Rules-Requires-Root: no * Drop X-Python3-Version, oldoldstable has 3.4 * Re-export upstream's OpenPGP keys in a minimal way Checksums-Sha1: f992c554d09d9c883ffb64016f7ee926a2abc769 1883 harmony_0.6.0-1.dsc 1800bc357d6910b948e1984130ca4c5de7664c81 26618 harmony_0.6.0.orig.tar.gz 528d7e95d0e0b538bde5fe266ffab7e868a737f4 4776 harmony_0.6.0-1.debian.tar.xz Checksums-Sha256: 5ccb36512334f44e593cf526994f7fcc2fd74588cb7f0dba614bd53ae082f734 1883 harmony_0.6.0-1.dsc 6f4202859376be28fc5934b0e327282b8cd403ed28b83b0259760b515d7db392 26618 harmony_0.6.0.orig.tar.gz 223d5a2e0ddbcbcaeb515080a345b7fe2605788019f198838f1f9adb296934d3 4776 harmony_0.6.0-1.debian.tar.xz Files: cc9ef3654b54c62539b7ff960227e5a1 1883 web optional harmony_0.6.0-1.dsc 1fc4aa7584da57e84c9cfdc1e1a3458b 26618 web optional harmony_0.6.0.orig.tar.gz f1a7a38c2773e185e6087d830241f8e5 4776 web optional harmony_0.6.0-1.debian.tar.xz -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEYQsotVz8/kXqG1Y7MRa6Xp/6aaMFAl0kSvUACgkQMRa6Xp/6 aaNT/hAAkAnFp0qFy3b80xedNa3BcD9FGIvebZlZPXLido2E9kzc5E0znD7K0ddE aBRHnn6Uv+SbqQGzJhVbxV/gsaJ8K75WwCy14zBWKr2PRx3+Zc/dqdGH6jFLUWoc YGfTjSfncZC+9IdV3PjQMEDqF+brRwGRAG/FEC2G1Glup+24RzTGiafid/LDkJLP DJu2wCALXwCKdoXwy61UNnPMCpUpKYJB841Yz+i/VECAdJH46B1xxdJ9jzKec3mX 0sphKdyF/Z9yDDL+GeeABST54A2tFIXCnyqInkDOCAxfN4+OcT1HsFOZsjsIUkWN J7UaqCISRBC1vcH/EPBEZQMYHPgXpAisz+CsfhvnFvnNcP3jv1tUTBJoZtvwMdS3 BntwsnMBm6QJeDVettBtXLzroiJRi7/qzfp+tCr/Qf0F8pl4kZoyQwXCVk6mW1wN duK79ggSetJOcBsgMeAoaMCx4bDvnad+0K+GUmFNSZR+LKZroF9NR/RIa44B0s4F lsNqANlFcIuwzvDYZWja1lPY6e4fZoQZiyzmUQgKwnRx4GXQAIWfXdBT4Jjlz40q F8kLOd1GMXk2LHVtpjkLw2A8bLYwhGaQbgHhu0Rwnmyba78bMn+OxXLhxNr/iqnK GfXS2H8tbo2BzDcEwJNY2TpkcvyjzrEJj5r8TywkMLW8fW37x08= =5zOy -END PGP SIGNATURE-
Accepted librecaptcha 0.6.2-1 (source) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Tue, 09 Jul 2019 14:58:32 +0800 Source: librecaptcha Architecture: source Version: 0.6.2-1 Distribution: unstable Urgency: medium Maintainer: Paul Wise Changed-By: Paul Wise Changes: librecaptcha (0.6.2-1) unstable; urgency=medium . * New upstream release - Now has a GTK UI available with --gui, add deps * Switch from debian/compat to debhelper-compat * Bump debhelper compat level to 12 * Bump Standards-Version to 4.4.0, no changes needed * Add Rules-Requires-Root: no * Drop X-Python3-Version, oldoldstable has 3.4 * Re-export upstream's OpenPGP keys in a minimal way * Add warning to description about rejection issues Checksums-Sha1: 01c7c5e65acaf722213f073a0af890048fa1d77b 2013 librecaptcha_0.6.2-1.dsc 28f2cf9a34124827632432da2ceb9d3c5c6265b1 29300 librecaptcha_0.6.2.orig.tar.gz 42b1edcf75c4c778c3119389608d2e4c59ef66c2 4648 librecaptcha_0.6.2-1.debian.tar.xz Checksums-Sha256: 9a32855819046d2b7d029af5d887d162593712467b9289dd639385147187211f 2013 librecaptcha_0.6.2-1.dsc 9f5fd5446563fa0e5c8cb46e89d5509f947c3872fa4186485c8d1eacc2ab1e70 29300 librecaptcha_0.6.2.orig.tar.gz de7f4de5c06fbbea1ef2d3ec6b0049ebdd13aea9f664e3d9521ffa7d80521926 4648 librecaptcha_0.6.2-1.debian.tar.xz Files: 0162b6a50ae470df54f81b5bd64aa415 2013 web optional librecaptcha_0.6.2-1.dsc 8dc9751973edd0b3ebae29935f35fe7a 29300 web optional librecaptcha_0.6.2.orig.tar.gz 4dd07047fb96ee4530cc9eb7dfdb3bd8 4648 web optional librecaptcha_0.6.2-1.debian.tar.xz -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEYQsotVz8/kXqG1Y7MRa6Xp/6aaMFAl0kPFAACgkQMRa6Xp/6 aaOC3A//ZVsxcQcZebaswZRM540NhyblnnTKu155vH2FJaRRaaJHiqeRRfGUSq+R mnHX//9OwqshCvRaeFo3fVAe4nGczIX1hHDL/NKzILPMCDzZn5U2gIzNltQs2lRh a82K0/zZRSf74K3ll9/qrt+ikoS5PkAPH3iWuAMXiSN3YHLBZWMhNskho6oic7r0 BCT/uadEY3A35WIMMphZNut4HY58udm5DYbdu7RLT1we+EBvLHj3gBnZ2UaKtfq4 ktXmSWHMvuKkblxKW50JAeVZWhQJ41jS/7APInqo2/HncIl800iFEe/NLDkX+BaH Y18tEsPBd47tYiJ2Ak3PPd68wm/hvwRNjP9nYVT3OuwWV9RYwjgkqmn6MM011xZu MQ6iDqJnTPZS1PP45ce8i2ak7l18fUv3Z4eNdtiicQwn7lYmbEhNX0sWg1VVgY0P KI5X1piTgqVzFHcGUR4GeYrPcWdnkndMWCB/AzWJsaIprb8juUOr6tmLuEe+ou// rVukUjlrbzhs0bYTcG32w7TMiIjaspmIj9v99IOJGVS34H952tQHF2fkADzjoiQ0 rGqxUwo6In4yvZkugZsN2sRhOaYdSgo+S7jRvJc/p7tYm9wVnvAVVRaP78y8L7f4 gB7gxsOjqHBW9vUOvRIIu5gKmpCch0RtWEt8ybiypeCtDvwHFt4= =kHUU -END PGP SIGNATURE-
Accepted purple-discord 0.9.2019.06.12.git.f8ea0ae-1 (source) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Tue, 09 Jul 2019 13:47:05 +0800 Source: purple-discord Architecture: source Version: 0.9.2019.06.12.git.f8ea0ae-1 Distribution: unstable Urgency: medium Maintainer: Paul Wise Changed-By: Paul Wise Changes: purple-discord (0.9.2019.06.12.git.f8ea0ae-1) unstable; urgency=medium . * New upstream snapshot * Bump Standards-Version, no changes needed * Bump debhelper-compat, no changes needed Checksums-Sha1: 28d6ab57df66d3873d1cc1f15987a758540af7f5 1999 purple-discord_0.9.2019.06.12.git.f8ea0ae-1.dsc fa80e9cf07290e01ed3d26e452b934ef2fabfb04 65706 purple-discord_0.9.2019.06.12.git.f8ea0ae.orig.tar.gz eccfa4224784394541618fd2c921561ec025a322 2524 purple-discord_0.9.2019.06.12.git.f8ea0ae-1.debian.tar.xz Checksums-Sha256: 0da0c66f1fc5befe8e43ee84d33247c453dd0e887ec64e0e8bf42bd462fa88e1 1999 purple-discord_0.9.2019.06.12.git.f8ea0ae-1.dsc 890ed1a1e6c8c7b8a7f031818d2af633b6dfb37989f53c80182be2e275bd1ff0 65706 purple-discord_0.9.2019.06.12.git.f8ea0ae.orig.tar.gz d39f932051f034cfc21166516a3aa5716ff2a962c916a86d7cf95d4c8fe414ae 2524 purple-discord_0.9.2019.06.12.git.f8ea0ae-1.debian.tar.xz Files: abe0f180225914d1ae11de67f0f6a4b1 1999 net optional purple-discord_0.9.2019.06.12.git.f8ea0ae-1.dsc 4b30a010b3064916d8e03170d1405a36 65706 net optional purple-discord_0.9.2019.06.12.git.f8ea0ae.orig.tar.gz 65e895ef81f24326f8739eee5c030a5d 2524 net optional purple-discord_0.9.2019.06.12.git.f8ea0ae-1.debian.tar.xz -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEYQsotVz8/kXqG1Y7MRa6Xp/6aaMFAl0kLMEACgkQMRa6Xp/6 aaNX5w//ZOX1PgQFQcm1nbnhS/yTGZiZbYNUSFZ2DLo67cNZN6CMtTMlr/ZwAuZL JD9WAgdOl0QvR7QdqlVsE0AiVfVZWFaYtkJnVXZLiotHiDgTqI4a9DHTPqfnHAHG 0zUNrIiSCYNLqvQhOjDcPI8Tp2SPwkspgi95EqkNA265Y3nHhiCIuUNXHiw3GW+f 0awaBPc3BPkd42tbA8CmjJQIfgIKWz1E+fxwUZwdSTlqNpEHrzblkUdZj2I9Yiql d3iJVr/f7a4lwvT+4soHJTazA7qwOjyLPP3Fan1Oegajc+MABIwauvwJt4i3SZco 5MRjpuX/QgGeeZemaJE9tpuqSwGZjyrcZYn3HmLc8VQM8S66qPMyZo+hsWRMn03e ylQDxyBfe1kwLTbJ1eIuKNYeV1Evy3PFMfdEG1uirkPTqw8ig4EiDoEuJU+K0tlV LrQCl9soZzEX+D8K25KZGkeKe1oHZw2H9DDRV4eDQXaokIwjlNivb1/BKKBONj5p w+UNY3H6pVxP0M0DWLOyFUaS5g5LoDKHH9Nxe3hNJxYRJVMNvUOiLwQdcvJ1NRq1 GI8XZVf09olU5zQUSvl2Ip4m5UVcAaHyhtcC2jhzsnrd6c+aHWnjH50DZguJ8sID Ak8ltSKUUUo8bd6G24KweXn+KYoa+upeQ/iCV/VQnzuyI789Zx8= =EEEY -END PGP SIGNATURE-
Re: The noudeb build profile and dh-only rules files
On Tue, Jul 9, 2019 at 7:42 AM Colin Watson wrote: >A memory-safe language with good testing support and a good testing >culture would be great, though it does also need to work on every >Debian architecture, which IIRC Rust doesn't quite; we've kicked >around the idea of maybe a stripped-down Python in the past, This reminded me of Keith Packard's "Python for embedded systems", Snek: https://keithp.com/snek/ -- bye, pabs https://wiki.debian.org/PaulWise
Re: Survey results: git packaging practices / repository format
On Thu, 2019-07-04 at 13:53 +0100, Ian Jackson wrote: > Does every DD have (i) access (ii) social authority, to make changes > to the upstream repo, the same way we do for the Debian package ? I was simply talking about standard upstream contribution mechanisms; pull requests, requests to pull from repos, patches on mailing lists etc. I assume that almost all upstream projects have one of these. -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Re: Survey results: git packaging practices / repository format
On Thu, 2019-07-04 at 12:19 +0100, Ian Jackson wrote: > What should another Debian contributor do, who wants to make a change > to the upstream source, but wants to do so in your own git workflow > and collaborate via your git branch, rather than by uploading a .dsc ? Do upstream changes upstream and packaging changes to the packaging repo. -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Re: Survey results: git packaging practices / repository format
On Thu, Jul 4, 2019 at 11:37 AM Russ Allbery wrote: > Ben Finney writes: > > > I don't recognise the repository structure that was raised by myself and > > some others: A VCS repository that contains only the Debian packaging > > files, which at build time is then exported to a non-VCS working tree > > and moerged with the upstream source. > > How do you handle needed changes to the upstream source? Or do you just > never make any changes to the upstream source? I make the changes upstream, make a new release (or wait for upstream to do so) and then update the Debian package. -- bye, pabs https://wiki.debian.org/PaulWise
Re: Let's consider using year based release identifiers [was: Re: getting rid of "testing"]
On Sat, Jun 29, 2019 at 8:16 PM Tomas Pospisek wrote: > Let's seriously consider using year based release identifiers. At this point in the thread it is very clear that which identifier one prefers is very individual and dependent on use-cases. So we should add support for more individuals and use-cases in order to accommodate everyone's preferences. Killing off use-cases by switching between identifier styles isn't the right way to go. I suggest that we add an "Aliases" field to the Release file. Then apt could use that to silence its warnings about sources.list not matching Suite/Codename. Then we could request ftp-master update dak to populate the Aliases field and add symlinks for all aliases. Any volunteers to write the needed patches? -- bye, pabs https://wiki.debian.org/PaulWise
Re: getting rid of "testing"
On Wed, 2019-06-26 at 14:54 -0400, Michael Stone wrote: > Wouldn't it be nicer to have a reliable and simple source of version > ordering rather than relying on ugly names and symlinks? As a bonus, it > would be useful for a lot more things and for more than n-2 > calculations. That doesn't seem useful for my use-case since it would mean I have to update my chdist sources.list after every release, while using the suite names doesn't require work after every release. I don't think this has to be a one-or-the-other scenario where the different use-case factions try to kill off the features used by other factions rather than living in harmony through co-existing features. I think we can support all use-cases quite simply by: Keeping the existing suite names and adding new *-backports ones. Adding a way for folks to use version-based sources.list entries. -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Re: getting rid of "testing"
On Tue, Jun 25, 2019 at 4:39 PM Paul Wise wrote:
> On Tue, Jun 25, 2019 at 2:08 PM Ansgar wrote:
>
> > what do people think about getting rid of current suite names ("stable",
> > "testing", "unstable") for most purposes? We already recommend using
> > codenames instead as those don't change their meaning when a new release
> > happens.
>
> I use these (testing, etc) so getting rid of them would be annoying.
I also should mention that I use all of stable stable-updates
proposed-updates and the equivalents for old/oldold. I have them in
the apt sources of a chdist so I can easily look up old versions, do
apt-file searches on old versions, look up non-amd64 architecture info
etc.
I would also love to have stable-backports be a thing, so I don't have
to change my chdist apt sources from codename1-backports to
codename2-backports every time a release happens.
I use chdist for when I'm offline or when I want to see what is on the
mirrors, since rmadison shows the ftp-master view.
PS: apt-venv is another option for this use-case.
--
bye,
pabs
https://wiki.debian.org/PaulWise
Re: getting rid of "testing"
On Tue, Jun 25, 2019 at 8:04 PM Michael Stone wrote: > Having "stable" in sources.list is broken, because one day stuff goes > from working to not working, which requires manual intervention, at > which point someone could have just changed the name. Having codenames > in sources.list is broken, because even people who have been developers > for two decades can't remember which release is which without looking it > up. (Which is harder than it should be; maybe we should have had > /etc/debian-releasenames or somesuch from the beginning. lsb_release -a > is helpful when available but doesn't have context, and many users don't > know it exists.) Personally, I can remember the names and their order much better than which version goes with which codename or suite :) -- bye, pabs https://wiki.debian.org/PaulWise
Re: getting rid of "testing"
On Tue, Jun 25, 2019 at 2:08 PM Ansgar wrote:
> what do people think about getting rid of current suite names ("stable",
> "testing", "unstable") for most purposes? We already recommend using
> codenames instead as those don't change their meaning when a new release
> happens.
I use these (testing, etc) so getting rid of them would be annoying.
> Related to that I would like to be able to write something like
>
> deb http://deb.debian.org/debian debian11 main
Already kind of possible:
deb http://deb.debian.org/debian Debian9.9 main
> Ubuntu already has no suite names, only codenames, but having to map
> "Ubuntu 18.04" to "bionic" instead of just writing the version in
> sources.list is annoying (I always have to look up the codename to be
> sure as I don't use Ubuntu that much).
They do have the 'devel' suite, but it is not a proper one:
https://bugs.launchpad.net/ubuntu/+bug/1821272
--
bye,
pabs
https://wiki.debian.org/PaulWise
Re: Key signing at SouthEast LinuxFest
On Thu, Jun 13, 2019 at 8:54 PM LeJacq, Jean Pierre wrote: > I'm hoping to have my key signed by a Debian Developer at the SouthEast > LinuxFest this coming weekend. The debian-events-na (North America) list might be a good place to repost this. https://lists.debian.org/debian-events-na/ In addition you might be interested in these wiki pages: https://wiki.debian.org/Keysigning/Offers https://wiki.debian.org/DebianLocations -- bye, pabs https://wiki.debian.org/PaulWise
Re: Debian, so ugly and unwieldy!
On Wed, Jun 12, 2019 at 10:34 PM Vincent Lefevre wrote: > I have gtk3-nocsd installed on my machines, but I don't think a > default install is a good idea, as its necessary use via LD_PRELOAD > breaks *any* program using ASan. The sanitisers shouldn't be used in production binaries due to security issues, so I think it is fine to require developers to unset LD_PRELOAD when debugging with the sanitisers enabled. http://www.openwall.com/lists/oss-security/2016/02/17/9 -- bye, pabs https://wiki.debian.org/PaulWise
Re: Question about Debian build infrastructure
On Wed, Jun 12, 2019 at 1:21 AM Benjamin Drung wrote: > * I had to patch reprepro to support multiple versions: > https://github.com/profitbricks/reprepro I think it would be very helpful to a lot of derivative distros and small or private apt repositories if this patch could be merged upstream and made available to Debian users. Has Profitbricks considered working on that? -- bye, pabs https://wiki.debian.org/PaulWise
Re: speeding up installs
On Sun, Jun 9, 2019 at 3:44 AM Adam Borowski wrote: > So if you took current d-i and planted it into a regular live image IIRC debian-live used to have that but it was too buggy so it got removed. Later Calamares replaced it. -- bye, pabs https://wiki.debian.org/PaulWise
Re: Debian, so ugly and unwieldy!
On Fri, Jun 7, 2019 at 11:24 PM Adam Borowski wrote: > In general: could we please do something to appearance beyond choosing a > wallpaper once a release? Please note that modifying the appearance of apps can annoy upstreams: https://stopthemingmy.app/ https://www.omgubuntu.co.uk/2019/05/open-letter-stop-gtk-theming-distros -- bye, pabs https://wiki.debian.org/PaulWise
Re: Removing bzip2 support from apt due to rustification
On Sat, Jun 8, 2019 at 10:09 AM Russ Allbery wrote: > Please let us have internal conversations without using them to > prematurely pick fights with external maintainers. It definitely wasn't my intention to pick a fight. I strongly disagree with hiding upstream problems from upstream developers. I wonder why our first reaction should be to have internal discussions instead of upstream discussions. To me that also seems rude, especially as we promised to communicate with upstream as part of the Social Contract. Thanks for your advice on this. -- bye, pabs https://wiki.debian.org/PaulWise
Re: Removing bzip2 support from apt due to rustification
On Sat, Jun 8, 2019 at 4:48 AM Julian Andres Klode wrote: > On Fri, Jun 07, 2019 at 03:36:08PM -0500, Federico Mena Quintero wrote: > > On Fri, 2019-06-07 at 11:48 +0800, Julian Andres Klode wrote: > > > > Why am I getting BCCed on this? Is this low-key unsolicited > > complaining like in https://mastodon.social/@juliank/102226793499538013 > > I did not BCC you, someone must have bounced it to you. You might > want to look at your mail headers to see how it got to you. I don't > even know your email address (well now I do...). I hope whoever did > it will step forward. That was me. I apologise for the confusion I generated. I get annoyed at people who don't CC the right people when sending mail. In this case I probably should have sent you Federico direct mail pointing at the archives instead. -- bye, pabs https://wiki.debian.org/PaulWise
Re: Bug#929834: Buster/XFCE unlock screen is blank
On Tue, Jun 4, 2019 at 4:12 AM Yves-Alexis Perez wrote: > My gut feeling is that light-locker just uses codepaths not really used > otherwise, like vt-switch at the same time as suspend/resume or screen off/on. > Unfortunately debugging i915 is completely out of my league (and I already > tried multiple time on other issues). I suggest reporting this to the Intel developers upstream, they should be able to diagnose the issue and hopefully provide a fix. -- bye, pabs https://wiki.debian.org/PaulWise
Re: paying people for Debian work (Re: Why do we take so long to realise good ideas (Was: Difficult Packaging Practices))
On Fri, May 31, 2019 at 5:32 AM Holger Levsen wrote: > LTS is accepted by the Debian community. I'm not entirely sure this fully represents the range of feelings about the LTS efforts. There are a few things that are possibly concerning: Freexian is essentially the only available-to-hire provider of services for Debian LTS, as the Freeside link doesn't lead anywhere useful. This means that Freexian essentially does not have any competition in the provision of these services. Individuals or companies who don't like Freexian's offering do not have any other choices, short of going to the general Debian consultants list, who may or may not have the needed skills and would take time to search through. https://wiki.debian.org/LTS/Funding The funding breakdown for the LTS team appears to be 48% Freexian, 31% volunteer/unknown, 21% other companies. I don't have any data on the proportion of LTS work done by each of these groups, but I get the feeling that the majority of LTS uploads are done by Freexian folks. This means that if Freexian decides to end its provision of services for Debian LTS, then the level of work done for LTS would go down significantly. Were this to happen, it would either significantly damage the image of Debian due to having to end the LTS effort or require us to do work which we have had a hard time finding volunteers for in the past. https://wiki.debian.org/LTS/Team There is strong coupling between Debian and Freexian in the language on the Debian LTS pages and the Freexian pages. This is free advertising for Freexian's LTS services and representing Freexian's LTS services as "blessed" by Debian or somehow "official", which could be objected to by other companies who might decide to provide security support services. It may be prudent to remove or alter the language on the Debian LTS pages. https://wiki.debian.org/LTS/Funding As far as I can tell, the sole communication between the LTS team and the list of individuals/organisations doing consulting around Debian is a mail attempting to recruit folks to work for Freexian. As far as I can tell, there has been no suggestion that individuals/organisations doing consulting around Debian add themselves to the list of organisations available to hire to work on LTS. This means that the individuals/organisations doing consulting around Debian miss out on the opportunities to work on LTS. https://www.debian.org/consultants/ https://lists.debian.org/msgid-search/20160502094142.ga19...@home.ouaza.com Freexian doesn't fund LTS contributors who are not DDs/DMs: this eliminates skilled developers from outside Debian who could contribute to LTS via Freexian and eventually work on Debian more generally. This seems to have prevented at least one former Debian member who was interested in Freexian's offer from contributing. It might also make LTS funding seem like a reward for Debian insiders. https://www.freexian.com/services/debian-lts-details.html#join https://lists.debian.org/msgid-search/calqvjpbwcpvr82jrmxmcwuga_mn7wot425-qftvpqpb7aa7...@mail.gmail.com The structure of using existing Debian contributors and funnelling most of the funding to them through one company reduces incentives for companies wanting security support to direct their employees to work on Debian security support. This means that our contributor base stays more static and reduces the chance that new folks will join us. An alternate model where each of the companies currently sponsoring Freexian LTS services instead directed their employees to spend some hours on Debian security support seems more likely to lead to new people getting involved. -- bye, pabs https://wiki.debian.org/PaulWise
Re: Exclude some architectures from an architecture-independent package ?
On Wed, May 29, 2019 at 8:46 PM Raphaël Halimi wrote: > What would be the "cleanest" solution according to you ? The cleanest solution would be to get this code into Linux mainline. Some discussion of workarounds: dak needs a way to restrict the availability of arch:all packages to certain architecture's Packages files. This would also be useful for interpreted code that only has support for certain kernel interfaces that aren't available on non-Linux kernels. For example for iotop I went with an arch:linux-any package instead of arch:all, the package is fairly small so the duplication isn't a big issue. Personally I think you should hardcode the ACPI architectures and accept the minor duplication. -- bye, pabs https://wiki.debian.org/PaulWise
Re: Why do we take so long to realise good ideas
On Wed, May 29, 2019 at 5:36 PM Mo Zhou wrote: > For example, many years ago I proposed that we could hire some > web developers to rewrite our homepage, to make it more good-looking > (Generally I don't care about superficial stuff but our homepage > is really old enough. Look at Gentoo's homepage and compare it with > the ancient version.) The web team has been working on this at their latest sprint. -- bye, pabs https://wiki.debian.org/PaulWise
Re: Some questions about DD status and salsa
On Tue, May 28, 2019 at 4:12 PM Ulrike Uhlig wrote: > - is a Salsa account created automatically for every DD? This includes > non-uploading DDs. Yes. > how does one recover the password? I expect the normal gitlab password reset works, I haven't tested it though. > /* I remember that the existence and usage of >https://db.debian.org/ is not well documented for new project >members. > */ The second paragraph of the welcome mail documents it: https://salsa.debian.org/dsa-team/mirror/userdir-ldap/raw/master/templates/welcome-message-Debian > can one create a non-guest account on Salsa? I think the answer is no, but I haven't checked the codebases used to prevent this. https://salsa.debian.org/salsa/ > Or are non-uploading DDs considered "guests" on Salsa? I think the answer is no. -- bye, pabs https://wiki.debian.org/PaulWise
Re: Some questions about DD status and salsa
MENGUAL Jean-Philippe wrote: > For non-uploading DD, is a salsa account created? I tried to auth > with it, but not possible, then to reset the passwd, but I dont > rceive mail to do it on @debian.org. Typos were made in the Debian LDAP data of another recently accepted Debian member and that was causing the process of importing Debian LDAP accounts into salsa to fail. I've fixed the typos and I'm informed by the Salsa admins that the next import should fix your issue. -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Re: Difficult Packaging Practices
On Mon, May 27, 2019 at 2:52 PM Vincent Bernat wrote: > People using tools like fpm will never get familiar with our tools and > will never be contributors. I enjoyed your blog post about pragmatic packaging using Debian's tools instead of fpm, it seems like a good approach if one is committed to using Debian, especially since it allows for incremental improvement towards a package that could even enter Debian. https://vincent.bernat.ch/en/blog/2019-pragmatic-debian-packaging OTOH I get the feeling that most FLOSS upstreams are interested in cross-OS and cross-distro packaging rather than Debian-specific packaging. I don't have a good feeling for how "sticky" OS/distro choices are for folks who are building non-FLOSS services on top of FLOSS distros. -- bye, pabs https://wiki.debian.org/PaulWise
Re: Bits from /me: A humble draft policy on "deep learning v.s. freedom"
On Fri, 2019-05-24 at 10:43 -0400, Sam Hartman wrote: > I wonder whether we'd accept a developer's assertion that some large pdf > in a source package could be rebuilt without actually rebuilding it on > every upload. As I understand it, ftp-master policy is that things in main be buildable from source using only tools in main, not that everything in main is actually built from source at `debian/rules build` time. There are plenty of things in the archive that we do not build from source on the buildds, firmware-linux-free for example. Obviously the best way to prove things are buildable from source is to actually build from source and do it as often as possible. Personally I'd like: * A standard build profile used when building everything from source. * A way to tell debian/rules to build everything from source. * A build toolchain option to make use of these. * A requirement that things not built from source come in a separate component tarball of the source package, using the multi-tarball feature of the v3 Debian source package format. * More upstream separation of build products from source. > I think we probably would. Personally I do not think it would be acceptable to not build large PDFs from source. I doubt the PDF build process could be problematic enough that we couldn't do it on current buildds. -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Re: Bits from /me: A humble draft policy on "deep learning v.s. freedom"
On Fri, 2019-05-24 at 03:14 -0700, Mo Zhou wrote: > Non-free nvidia driver is inevitable. > AMD GPUs and OpenCL are not sane choices. So no model which cannot be CPU-trained is suitable for Debian main. > Don't doubt. Nouveau can never support CUDA well. There is coriander but nouveau doesn't support OpenCL 1.2 yet. https://github.com/hughperkins/coriander > Some good Xeon CPUs can train models as well, > and a well optimized linear algebra library > helps a lot (e.g. MKL, OpenBLAS). But generally > CPU training takes at least 10x longer time to > finish. (except some toy networks) So only toy networks can enter Debian main? > Sounds like a good way to go. But not today. > Let's do lazy execution at this point, and > see how this subject evolves and how other > FOSS communities think. Agreed, that sounds reasonable, similar to how repro builds went. -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Re: Bits from /me: A humble draft policy on "deep learning v.s. freedom"
On Fri, May 24, 2019 at 1:58 AM Sam Hartman wrote: > So for deep learning models we would require that they be retrainable > and typically require that we have retrained them. I don't think it is currently feasible for Debian to retrain the models. I don't think we have any buildds with GPUs yet. I don't know about the driver situation but for example I doubt any deep learning folks using the nvidia hardware mentioned in deeplearning-policy are using the libre nouveau drivers. The driver situation for TPUs might be better though? Either way I think a cross-community effort for retraining and reproducibility of models would be better than Debian having to do any retraining. -- bye, pabs https://wiki.debian.org/PaulWise
Re: Bits from /me: A humble draft policy on "deep learning v.s. freedom"
On Tue, 2019-05-21 at 03:14 -0700, Mo Zhou wrote: > They are added to the case study section. Are there any other case studies we could add? Has anyone repeated the training of Mozilla DeepSpeech for example? Are deep learning models deterministically and reproducibly trainable? If I re-train a model using the exact same input data on different (GPU?) hardware will I get the same bits out at the end? -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Re: Bits from /me: A humble draft policy on "deep learning v.s. freedom"
On Tue, May 21, 2019 at 3:11 PM Mo Zhou wrote: > I'd better write a draft and shed some light on a safety > area. Then here is the first humble attempt: > > https://salsa.debian.org/lumin/deeplearning-policy The policy looks good to me. A couple of situations this related to this policy: https://bugs.debian.org/699609 https://ffmpeg.org/pipermail/ffmpeg-devel/2018-July/231828.html -- bye, pabs https://wiki.debian.org/PaulWise
Re: NMUs: Do we want to Require or Recommend DH
On Wed, May 15, 2019 at 2:31 AM Sam Hartman wrote: > How do we feel about people making build system conversions when those > conversion make it easier to fix some other bug that they are fixing as > part of an NMU? If the maintainer is MIA enough to not express an opinion when asked if adding a dh conversion to the NMU is fine, probably the package should be orphaned/salvaged instead of NMUed, which would bring the dh conversion into scope. -- bye, pabs https://wiki.debian.org/PaulWise
Re: Do we want to Require or Recommend DH
On Mon, May 13, 2019 at 8:34 PM Sam Hartman wrote: > As promised, I'd like to start a discussion on whether we want to > recommend using the dh command from debhelper as our preferred build > system. This is already the case AFAICT. > But I think what we're really talking about is whether maintainers > should be expected to apply well-written patches to convert a package to > using dh. That is, is not using dh a bug. > > And at some level I think we're asking whether it is appropriate to NMU > a package to convert it to dh. > > Today at least I don't think we're talking about making not using dh an > RC bug. It would not make a lot of sense to me to start there. I don't think these are appropriate. I think conversion to dh should only be done when doing hostile hijacking of packages, salvaging packages, adopting packages, orphaning packages or team/maintainer uploads and only if the person doing the conversion builds the package twice (with and without dh), inspects the resulting changes to the binary packages with diffoscope and is confident that each change is appropriate. > Exceptions > == I think we should allow the cdbs maintainer to use cdbs instead of dh in their packages :) > so, what do you think? I don't think there is any way to require packages use dh, unless you want to forcibly remove/orphan packages or remove maintainers that won't use dh? I think that we should encourage experimentation with better alternatives to dh, such as if someone wanted to revive the efforts to build Debian packages using Gentoo's ebuild framework. http://penta.debconf.org/dc7_schedule/events/69.en.html -- bye, pabs https://wiki.debian.org/PaulWise
Accepted corekeeper 1.7 (source) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Sat, 04 May 2019 14:53:44 +0800 Source: corekeeper Architecture: source Version: 1.7 Distribution: unstable Urgency: medium Maintainer: Paul Wise Changed-By: Paul Wise Closes: 924397 924398 Changes: corekeeper (1.7) unstable; urgency=medium . * Do not use a world-writable /var/crash with the dumper script and fix the permissions on upgrade as dpkg doesn't do that. (Closes: #924397) (See-also: #515211) * Handle older versions of the Linux kernel in a safer way (Closes: #924398) * Harden ownership determination and core file names * Do not truncate core names for executables with spaces * Update VCS URLs from alioth to salsa Checksums-Sha1: 92af0ea48086f93371afdeec82e3168ea7868188 1535 corekeeper_1.7.dsc 178dc81ae008210bb9623fb0838ff87844630da7 6124 corekeeper_1.7.tar.xz Checksums-Sha256: c6369fba3a211a145c8afecb6c6e761670d44bbf751849622fc584ec0e446f31 1535 corekeeper_1.7.dsc 353dbcc4ae320ed1cc415f8cc0971e9d559e9be3e4afdf56c860216b99d75a48 6124 corekeeper_1.7.tar.xz Files: 3fa5bad85732792ceefdc5a9e6389c9f 1535 admin extra corekeeper_1.7.dsc 65f9483e5ea428c7d29945fe42338979 6124 admin extra corekeeper_1.7.tar.xz -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEYQsotVz8/kXqG1Y7MRa6Xp/6aaMFAlzXkx0ACgkQMRa6Xp/6 aaMprw/+IoiXiA5covM6vgK2NAe6iiAn6T8jItXt8pqdT9zltFXW2ukPVgMUoWSN IfQ72M8CuP4WH3zvse33LVBk+kb1f07h0amQQAAnOhFA4qWsLpQTxwoBQEyT6Ukw iWiXnWJEOEvwkGCOtJ6d6z0XL+GNJmkAKaqkXd4lyxLBzORkZlNt54QQDlDQy/kY nw/sgKE/qQxXrdetMOL40fW/fZrSiMdeSjNxbiC5rsZsAfGEG4hPB1h9g2+kLoRE q6vpgmrO9VtSYCall7FsGSixwtOA3Y321RujEEG+NhfPgWs4H6XLz0DqeFfdtdNh pNS58+kvQHQZTfkOGYgOGaIG8RILniF7/O/5rZtizJKBx0zkQ4R99NLhjkhosLzV gaqnv8s375g5qe+7O0jdRiJXPg5s5CYa0NLlSe310xLSdfgSCejfl9ba5Uwr2ATU Tj1uBMce5Df8vVdcitp+ETeWtJRFbYqBvwwAOkDLtj2eBeH60cKT0KqKRVQkw4Ta zKuMACePp7Zbg6PGscA1oQlkaNJupEQ7SXYB1tGhFl86PSSoqE7Sw2cojfe7mi09 0yUnofc60P/qqQnfIjcreMSbRfd/GLUlDqDkCMle/d5bWY3oU9Zx5e9CDhnyX0rK fRZqGRRzmUgLHw95I7X7D6Ddyvghxfz3EVMdBohjS7rzTmxhwkk= =tX2/ -END PGP SIGNATURE-
Re: Configure your PC to contribute to Debian community
On Wed, May 8, 2019 at 9:27 PM Vipul wrote: > I've been using Debian from couples of years but haven't contributed yet back > to community. There are a number of different ways to contribute to Debian: https://www.debian.org/intro/help > I want to contribute to Debian by maintaining packages and fixing bugs. The best way to contribute is to work on packages that you use and the best way to find opportunities for that is to install and run the how-can-i-help package: https://wiki.debian.org/how-can-i-help > Is there a way to get isolation for work & contribution purpose to keep > yourself organized? If you do not have a spare computer, the best option would be a virtual machine, since you can then test newer versions of the whole system. Some options for this include gnome-boxes or virt-manager. > I want to hear from contributors & maintainers Which method they are using or > prefer to get isolation? Personally I'm using Debian testing and do package building in pbuilder chroots of unstable. -- bye, pabs https://wiki.debian.org/PaulWise
Re: .deb format: let's use 0.939, zstd, drop bzip2
On Thu, May 9, 2019 at 1:38 AM Adam Borowski wrote: > Thus, even though we'd want to stick with xz for the official archive, speed > gains from zstd are so massive that it's tempting to add support for it, > at least for non-official uses, possibly also for common Build-Depends. Could we use custom zstd dictionaries on a per-architecture basis to further reduce the size of zstd packages, possibly allowing it to beat xz? -- bye, pabs https://wiki.debian.org/PaulWise
Re: Fw: Re: Monero Client on Tails/Debian
On Mon, May 6, 2019 at 9:42 AM wrote: > We've been discussing possible Monero implementation into Debian and not sure > how we can proceed. It sounds like Monero is only suitable for Debian experimental due to the rate of upstream introducing backwards-incompatible versions. > AppImage, maybe? Debian doesn't distribute any of the alternative packaging formats, so you'll have to distribute them yourself or use the appropriate repositories for them: https://appimage.github.io/ https://www.appimagehub.com/ https://www.flathub.org/ https://snapcraft.io/store > It would be very beneficial to all three communities (Debian, Tails and > Monero) for a Monero client, either lightweight or full client to be > developed for Debian but we need some help from your team as well. The documentation for getting software into Debian is here: https://mentors.debian.net/intro-maintainers -- bye, pabs https://wiki.debian.org/PaulWise
Re: Preferred git branch structure when upstream moves from tarballs to git
On Tue, Apr 30, 2019 at 9:03 AM Ben Finney wrote: > My opinionated recommendation: Track the Debian packaging in a separate > repository (which contains only the ‘debian/’ directory tree). When it's > time to build the Debian source package for testing, export the upstream > source to a temporary build directory and export the Debian packaging > onto that. Build the Debian source package from the result. I like this option because it still works well if we ever decide to fix a fundamental flaw in the Debian source package layout. The directory hierarchy we use is inverted from one that would be logical based on the relationship between the components of the Debian source package. The Debian packaging (especially debian/rules) wraps and controls the interaction of the Debian tools with the upstream source but the debian/ directory is located inside the upstream source instead of the upstream source being a subdirectory of the Debian packaging. -- bye, pabs https://wiki.debian.org/PaulWise
Re: PPAs (Re: [Idea] Debian User Repository? (Not simply mimicing AUR))
On Fri, Apr 12, 2019 at 3:27 PM Simon McVittie wrote: > Flatpak treats /usr as immutable (with the exception of mounting > "extensions" on pre-prepared empty directories) and mounts it read-only in > the container. If it didn't, it wouldn't be able to use content-addressed > storage (the storage can't be content-addressed if the content changes). > In the usual way to use Flatpak, with a shared runtime for a family of > related packages like "the GNOME apps", apps would end up accidentally > or deliberately modifying each other's runtimes if they weren't read-only. I expected the Flatpak /app directory to also be entirely read-only, are there parts of /app that are not read-only? > If the user-facing leaf package is really installed in the runtime, with > a different runtime for each user-facing leaf package, you're right that > the Flatpak app could mostly contain symlinks into /usr. A few metadata > and integration files that get "exported" to the host system (such as > .desktop files and icons) would have to be copied instead of symlinked, > because the host system needs to be able to read those without entering > the container. It sounds like my idea might be a viable way to generate automatically Flatpaks directly from leaf Debian packages then, thanks for the info. I might at some point take a look at adding such a mode to flatdeb, would you accept having that as an option? > flatdeb installs apt/dpkg/essential, but then deletes apt, dpkg and ... Yeah, I noticed that so I was glad when mmdebstrap's sub-essential stuff came along. > The matching SDK runtime that is used to compile apps I don't know enough about SDKs in the Flatpak world, would they contain something like the Build-Depends and their recursive deps? > Instead of using sudo or ssh to a remote (usually virtual) machine to > get root so that it can run debootstrap and dpkg, flatdeb now runs debos > on the local machine. This means it's root in debos' temporary qemu VM, > and doesn't need privileges other than /dev/kvm access in the host system. That sounds like a much better design. > In principle there'd be nothing to stop debos from using something > like user-mode-linux as an alternative to qemu/KVM. I guess you could also use container tools like systemd-run with user namespaces (once those are enabled by default)? > One per desktop task, plus one for the Priority >= standard default > CLI installation, would be quite a lot of data but could be good for > bisecting, yes. I'd suggest doing this with debos, which has built-in > support for committing trees to libostree and doesn't need root on the > host system. Cool, thanks for the information :) -- bye, pabs https://wiki.debian.org/PaulWise
Re: PPAs (Re: [Idea] Debian User Repository? (Not simply mimicing AUR))
On Thu, Apr 11, 2019 at 7:01 PM Simon McVittie wrote: > The "app" (directly-user-facing part) in a Flatpak package will be mounted > on /app and so is expected to be built with --prefix=/app, so you can't > reuse a compiled binary .deb unless it's for something that happens to be > relocatable already. The runtime (chroot-like library stack to run apps) > is built with --prefix=/usr, so it's usually easy to reuse binary .debs > for that. Has anyone done any rebuild testing to see how many packages hard-code the prefix in their binaries? Having to recompile everything once more for each "app" package seems like a lot of extra CPU time. Is there any reason that making /app a symlink to /usr (or a directory containing only links to /usr) wouldn't work inside Flatpak packages? I had planned to do this using mmdebstrap, which now offers installation of Debian systems that don't have apt/dpkg/essential, by using the new dpkg root stuff. I was blocked by the lack of a DPKG_CONFIG variable though, otherwise the system dpkg config interferes with the process if you have certain packages installed. > https://gitlab.collabora.com/smcv/flatdeb builds Flatpak runtimes from > an apt repository using debos and debootstrap. Hmm, last time you presented flatdeb, it wasn't using debos, how does debos get used in flatdeb now? > The example runtime recipes provided with > flatdeb are "Base" ... and "Games" I still think one runtime per "app" package is the way to go. It might also be interesting to start importing the standard Debian installations into an OSTree archive, so we could do things like bisect bugs between stable and current sid. As well as share files between all the runtimes and apps. -- bye, pabs https://wiki.debian.org/PaulWise
