Re: Bug#954313: dh_installchangelogs: provide option to strip off old changelog entries
Control: tags -1 moreinfo Michael Biebl: > Package: debhelper > Version: 12.9 > Severity: wishlist > > Hi, > Hi, Thanks for the suggestion. :) (CC'ing d-devel because I think this is relevant to the discussion there) > some packages have a very detailed debian/changelog which goes back > years or even decades. > > Given that we nowadays have the ability to get changelogs on-demand via > "apt changelog", I think it would make sense if the changelog.Debian > that is installed on disk can be trimmed down. > > While I surely can do that via some sed hacks in debian/rules, a nicer > option would be, if dh_installchangelogs would provide an option like > say --trim=365d / --trim=2y / etc, which would only install changelog > entries that are newer then 365 days / 2 years / etc. > > 2 or 3 years sounds like a good compromise to me, as this would cover > changelog entries dating back to the last stable release. > > For the time being, I would make that opt-in, i.e. packages have to > override dh_installchangelogs. Maybe at some point in the future, > something like --trim=3y could be made the default behaviour with a new > compat bump. > > I vaguely remember that Ubuntu does something similar in that regard. > I've CCed Julian, maybe he can provide some input. > > Regards, > Michael > > [...] I think we owe ourselves to be honest and agree whether we do this or not. The proposed opt-in solution will almost certainly end up being a slow translation to saying "yes we are going to do this" - it will just defer the answer 5 - 10 years with a lot of extra work. And if we are going to that, I would rather do it fully automatic from the start. Either "flag day"-style or "next compat level"-style. This would save everybody else time and energy learning and unlearning a command option that you have to sprinkle into your package to have debhelper "DTRT". And would save me from adding an option and then spend a decade removing it again because it has become obsolete[1]. Lets not add "yet another papercut" to our packaging process. On the topic of derivatives: I am happy to hear from derivatives that have different needs for changelog trimming. As mentioned in the d-d thread, there is Ubuntu which is currently the only one I am aware of. ~Niels [1] The time spent removing features from debhelper is literally measured in decades.
Repeated Debian WiFi problem
I have tried LIVE Debian Plasma, Debian LXQt and Mint LMDE (Debian Environment) with an ASUS N53 USB Wireless adapter, and none of the Debian systems are able to connect to my WiFi signal. All other distros used (Ubuntu versions, MX Linux, Linux Puppy, Porteus, and KDE Neon) easily connect to my WiFi signal. I tried to find instructions on how to configure the ASUS adapter, and found none. I found suggestions on where to download a driver, but that is not helpful when I am running LIVE from a USB with no WiFi connection. *In future Debian versions, could you please include the ASUS driver in the standard package?* *The model number is the ASUS N53 USB WiFi adapter with the rt3572 chip.* I see on your website that ASUS N53 USB adapters with different chips have similar problems. I otherwise enjoy Debian distros and would like to use them on a regular basis, but I cannot when it does not connect to WiFi. This apparently has been an issue since 2013. My unit is only two years old. Thank you, Peter Pynchon
Re: Repeated Debian WiFi problem
On Sun, 22 Mar 2020 02:20:18 -0700, Peter Pynchon wrote: >I have tried LIVE Debian Plasma, Debian LXQt and Mint LMDE (Debian >Environment) with an ASUS N53 USB Wireless adapter, and none of the Debian >systems are able to connect to my WiFi signal. All other distros used >(Ubuntu versions, MX Linux, Linux Puppy, Porteus, and KDE Neon) easily >connect to my WiFi signal. Please take user questions to the regular support channels, debian.org/support. >*In future Debian versions, could you please include the ASUS driver in the >standard package?* *The model number is the ASUS N53 USB WiFi adapter with >the rt3572 chip.* I see on your website that ASUS N53 USB adapters with >different chips have similar problems. Does the driver need non-free firmware? If yes, the card will probably never work out of the box in Debian proper, and you might need to install the firmware manually. Doing this will most probably solve your issue with current Debian as well. The best idea is to change to a Wifi adapter that has better support. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber | " Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom " | Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
Re: Bug#954313: dh_installchangelogs: provide option to strip off old changelog entries
Niels Thykier wrote: > I think we owe ourselves to be honest and agree whether we do this or > not. The proposed opt-in solution will almost certainly end up being a > slow translation to saying "yes we are going to do this" - it will just > defer the answer 5 - 10 years with a lot of extra work. > > And if we are going to that, I would rather do it fully automatic from > the start. Either "flag day"-style or "next compat level"-style. Agreed. One request as well: let's *please* not base any aspect of this on the current date; that would make builds not reproducible. Instead, let's base this on the date of the most recent changelog entry. Concrete proposal for something that will hopefully keep people reasonably happy as a default, and should result in reproducible builds: - Keep a list of Debian release dates in debhelper. - Look in the changelog for the most recent entry that looks like a normal upload to unstable (not a stable update or security update); that way, we have a full record of all stable/security updates. - Compare the date of that changelog entry to the Debian release dates plus 7 days of additional slack (to allow for slightly mis-dated changelogs, time zone issues, or similar). - Keep changelog entries going back to the preceding release, or 10 changelog entries, or until the last time the upstream version number changed, whichever is largest. - Provide one additional option to keep only N entries maximum regardless of the above heuristic; that will help packages that have huge changelogs, or exclusively Debian revisions and no new upstream version. Does that sound like a reasonable default? - Josh Triplett
installing minimal systems with weeed out /u/s/d (was: trimming changelogs)
On Fri, 20 Mar 2020 10:16:00 +0100, David Kalnischkies wrote: >On Fri, Mar 20, 2020 at 12:50:29AM +0100, Adam Borowski wrote: >> In the rush for cutting away small bits of minbase, it looks like we forgot >> a big pile of junk: /usr/share/doc/ > >Honestly, on space constraint systems, isn't the whole /usr/share/doc >directory "junk". Probably not the solution for everyone or as >a default, but I want to highlight that dpkg supports excluding files >and entire paths from being unpacked: > >$ cat /etc/dpkg/dpkg.cfg.d/01_exclude_paths >| path-exclude /usr/share/doc/* >| path-include /usr/share/doc/*/copyright >| >| path-exclude /usr/share/locale/* >| path-include /usr/share/locale/en* >| path-exclude /usr/share/man/* >| … Is there any canonical way to have a new system/chroot installed that way? Debootstrap seems to make things particularly hard without using internal interfaces (#811269, #864981, #871255, the oldest of those having had its fourth birthday recently, with only a single less-than-helpful maintainer interaction since then). How would I do that from the very beginning? >Sure, all these files are handy to have on a "normal" system, but that >is the point: If I want to look at them, I want to do that 99,9% of the >time on a normal system, not on a single-purpose minbase(based) one – >where I don't even have a sane editor available (SCNR). Amen. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber | " Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom " | Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
Re: installing minimal systems with weeed out /u/s/d (was: trimming changelogs)
Hi, Quoting Marc Haber (2020-03-22 12:20:37) > On Fri, 20 Mar 2020 10:16:00 +0100, David Kalnischkies > wrote: > >On Fri, Mar 20, 2020 at 12:50:29AM +0100, Adam Borowski wrote: > >> In the rush for cutting away small bits of minbase, it looks like we forgot > >> a big pile of junk: /usr/share/doc/ > > > >Honestly, on space constraint systems, isn't the whole /usr/share/doc > >directory "junk". Probably not the solution for everyone or as > >a default, but I want to highlight that dpkg supports excluding files > >and entire paths from being unpacked: > > > >$ cat /etc/dpkg/dpkg.cfg.d/01_exclude_paths > >| path-exclude /usr/share/doc/* > >| path-include /usr/share/doc/*/copyright > >| > >| path-exclude /usr/share/locale/* > >| path-include /usr/share/locale/en* > >| path-exclude /usr/share/man/* > >| \u2026 > > Is there any canonical way to have a new system/chroot installed that > way? Debootstrap seems to make things particularly hard without using > internal interfaces (#811269, #864981, #871255, the oldest of those > having had its fourth birthday recently, with only a single > less-than-helpful maintainer interaction since then). > > How would I do that from the very beginning? in practice, tools like debootstrap first extract the data part of the base *.deb packages using "dpkg-deb --fsys-tarfile", also called first-stage installation. Afterwards, packages are installed using "dpkg --install" from inside the chroot (this is often called the second stage). Since package data was already unpacked, the "dpkg --install" command will *not* remove the files indicated by --path-excluded. To make dpkg remove these files, a second "dpkg --install" has to be performed. Since debootstrap cannot do that yet (as indicated by the open bugs you cite), you'd have to chroot into your debootstrap rootfs and call "dpkg --install" again with all the packages affected by your chosen --path-exclude option. If you don't want to do this manually, then you can also use mmdebstrap instead of debootstrap and use its --dpkgopt option. For examples look at its man page or in the other message I wrote to this thread. Thanks! cheers, josch signature.asc Description: signature
email backend for fedmsg
Hello! Ad. https://lists.debian.org/debian-devel/2016/07/msg00377.html - fedmsg usage in Debian. There is a note: "it seems that people actually like parsing emails" What about adding email backend to fedmsg then. Wouldn't it be an interesting idea? It could basically rely on postfix for sending messages, hence providing decentralization as well as high reliability. I think that amount of events that happen in distribution (like package update, package build) is never so huge that email infrastructure wouldn't handle it and also the machine mailing infrastructure could be optionally be separated from the human one if needed. So fedmsg would become a tiny wrapper over email that would just serialize and parse json data to and from email messages and check signatures. I am asking because I like the idea of distribution-independent infrastructure message bus that this project had. Btw. instead of json, yaml could be used so it is nicer to human eyes. clime
Re: Announcing Debian Social
On Thu, Mar 19, 2020 at 11:59:48PM +0100, Rhonda D'Vine wrote: > Long-term, we plan to authenticate these services against the salsa.debian.org > service. Some services are part of the way there, others may take some more > time and collaboration with upstream. I want to highlight this bit. In the past formorer said no to this, as he doesn't want salsa to end up like alioth and be used for too many things. In particular, he said he wouldn't want anybody to rely on salsa as a user database. sso.d.o. is the thing that should be used instead (but it's still lacking a proper guest account backend). That said, recently somebody else also rised this issue in #alioth, and it turns out that the salsa admins team is not really on the same page on this. -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. More about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature
Re: RFC: Replacing vim-tiny with nano in essential packages
On Mon, Mar 16, 2020 at 11:06:11AM +0100, John Paul Adrian Glaubitz wrote: > Debian Ports is affected by this problem in particular because we don't have > the cruft feature in mini-DAK [3], so every time I build a debian-installer > image and forget checking whether vim build successfully on every > architecture, > the particular debian-installer image becomes unusable because debootstrap > cannot install vim-tiny as its version mismatches the version of vim-common. > The debian-ports archive maintainers could decide to change vim-tiny's priority on their side, without imposing that decision on the debian archive. Cheers, Julien
Re: RFC: Replacing vim-tiny with nano in essential packages
On 3/22/20 3:48 PM, Julien Cristau wrote: > On Mon, Mar 16, 2020 at 11:06:11AM +0100, John Paul Adrian Glaubitz wrote: >> Debian Ports is affected by this problem in particular because we don't have >> the cruft feature in mini-DAK [3], so every time I build a debian-installer >> image and forget checking whether vim build successfully on every >> architecture, >> the particular debian-installer image becomes unusable because debootstrap >> cannot install vim-tiny as its version mismatches the version of vim-common. >> > The debian-ports archive maintainers could decide to change vim-tiny's > priority on their side, without imposing that decision on the debian > archive. And the opinion of the vim maintainer that he would like to get rid of the vim-tiny package is not relevant? Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: RFC: Replacing vim-tiny with nano in essential packages
On 3/16/20 12:31 PM, Thomas Pircher wrote: > John Paul Adrian Glaubitz wrote: >> I would like to suggest to replace vim-tiny with nano as the default minimal >> editor installed with debootstrap and therefore debian-installer. > > Would you consider nvi as an alternative to vim-tiny? It is quite small > and is functional enough to edit the occasional config file when > necessary. FWIW, there is also vile [1] which is a small vim clone which is also currently maintained, both in Debian and upstream. Adrian > [1] https://packages.qa.debian.org/v/vile.html -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
MBF? ftbs
Hi! There's a bunch of packages that fail to repack their sources. That is, "dpkg-buildpackage -S" fails in a clean environment. I've tested the entire archive, invoking: sbuild -s --source-only-changes --no-arch-all --no-arch-any The list below includes all packages which fail the repack but don't FTBFS on a binary-only build (on amd64). I wonder what would be the appropriate severity: the Policy is clear, but no one filing bugs for failure to repack suggests it's nowhere bad enough to brandish the RC stick. Meow! -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ in the beginning was the boot and root floppies and they were good. ⢿⡄⠘⠷⠚⠋⠀ -- on #linux-sunxi ⠈⠳⣄ adduser anki apt-xapian-index arandr aspell-it aspell-mr aspell-or aspell-pa aspell-pl aspell-sl aspell-te autoradio beaker biojava4-live bleachbit blends bless boilerpipe bookletimposer c++-annotations c3p0 caveconverter cecil cecil-flowanalysis cl-abnf cl-anaphora cl-asdf-finalizers cl-asdf-system-connections cl-chunga cl-closure-common cl-command-line-arguments cl-containers cl-curry-compose-reader-macros cl-cxml cl-daemon cl-db3 cl-drakma cl-dynamic-classes cl-esrap cl-ftp cl-garbage-pools cl-github-v3 cl-graph cl-ieee-floats cl-iterate cl-ixf cl-local-time cl-log cl-lparallel cl-markdown cl-metabang-bind cl-metatilities-base cl-mssql cl-parse-number cl-postmodern cl-py-configparser cl-qmynd cl-quri cl-rfc2388 cl-salza2 cl-sqlite cl-trivial-utf-8 cl-utilities cl-uuid cl-who cl-yason cl-zip cl-zs3 classycle cmd2 cme colplot commons-pool configparser context-nonfree cstore-fdw darcula db4o dblatex dbus-sharp dbus-sharp-glib debian-astro debian-electronics debian-gis debian-hamradio debian-junior debian-med debian-multimedia debian-science debichem deepdiff deluge django-axes django-ipware django-stronghold django-tables django-taggit djvubind docbook-xml dput dstat dynalang editorconfig-core-py elasticsearch-curator fdb foiltex fonts-arundina fop fortunes-debian-hints freelan freeplane freezegun fsplib funnyboat gandi-cli germinate getmail git-publish gmetric4j gourmet gprolog gramps guessit gvb hgsubversion hijra howm hunchentoot imagej ipxe isenkram isorelax jaligner jargs jclic jcommander jheatchart jlha-utils jruby-joni jsxgraph jtb jupyter-sphinx-theme jvyamlb jxplorer klaus kunststoff kupfer latex-make latex2html lazygal ledger-autosync lfm libbasicplayer-java libcgi-application-perl libcgi-application-plugin-authentication-perl libcgi-application-plugin-devpopup-perl libcgi-application-plugin-tt-perl libcobra-java libcommons-discovery-java libcommons-jexl-java libconfig-model-dpkg-perl libconfig-model-itself-perl libconfig-model-perl libdist-zilla-perl libezmorph-java libgpiod libitext1-java libjcip-annotations-java libjdom2-java libjlha-java libjmac-java libjorbis-java libjspeex-java libjt400-java liblastfm-java libmp3spi-java libpal-java libpdfbox-java libpixie-java libproxool-java libswarmcache-java libvorbisspi-java libyanfs-java logilab-common logilab-constraint mcomix messagingmenu-sharp metastudent minidb mobile-atlas-creator monajat mono-addins mono-tools mpd-sima mpmath mpris-remote multistrap myhdl nant nbsphinx nekohtml net-luminis-build-plugin netbeans-cvsclient nini notify-sharp notify-sharp-3.0 ntlmaps ocaml-qtest ognl onionbalance osmnx othman pagekite paste pastescript pdfposter pflogsumm pg-fact-loader pglogical pglogical-ticker piccolo pixelmed pixelmed-codec plm png-sixlegs ponyorm postgis-java pppconfig pylint pyracerz pyro4 pyroma python-amqp python-arrow python-bottle python-cookies python-daemon python-django-braces python-django-crispy-forms python-django-registration python-django-treebeard python-docutils python-dotenv python-elasticsearch python-flickrapi python-gitlab python-hug python-ipcalc python-irc python-k8sclient python-l20n python-ldappool python-libusb1 python-marshmallow python-nmap python-prometheus-client python-pydub python-pygal python-pytest-cov python-q python-repoze.tm2 python-requests-toolbelt python-roman python-scrapy python-smstrade python-socksipychain python-tempita python-u2flib-server pyvo rafkill recommonmark resteasy3.0 rst2pdf runsnakerun sardana sat4j scons-doc seahorse-adventures serpent shatag simplyhtml sisc smuxi solaar solarwolf solfege sphinx spyne squaremap svgsalamander swing-layout swtcalendar taoframework tp-smapi translate-toolkit uc-echo uncertainties unittest2 urlscan urlwatch usb-modeswitch-data velocity-tools virtualenvwrapper volume-key w3c-linkchecker weather-util webcheck webtest weresync werken.xpath woof xdeb xhtml2pdf xom yapps2 yapsy yaret yorick-cubeview Aggelos Avgerinos elasticsearch-curator (U) Agustin Henze configparser yapsy Agustin Henze python-pygal (U) Alexandre Rossi lazygal (U) Andrea Capriotti autoradio Andrea Colangelo python-roman (U) Andrea Colangelo woof (U) Andrea Gasparini woof Andreas Bombe anki Andreas Tille blends (U) debian-gis (U) debian-med (U) debian-scien
Re: Announcing Debian Social
On Sun, Mar 22, 2020 at 03:09:07PM +0100, Mattia Rizzolo wrote: > I want to highlight this bit. > In the past formorer said no to this, as he doesn't want salsa to end up > like alioth and be used for too many things. In particular, he said he > wouldn't want anybody to rely on salsa as a user database. sso.d.o. is > the thing that should be used instead (but it's still lacking a proper > guest account backend). For the records, I consider sso.debian.org as it is now, past its "best before" date, and starting to smell quite bad. A replacement attempt was written, but hasn't been deployed for far too long. I'd love to be able to have the current SSO replaced: it's currently far too high a barrier of access for nm.debian.org and contributors.debian.org for non-DDs, to a point that worries me significantly. What we replace it for, is probably not up to me to choose, although being responsible for maintaining the two current biggest consumers of SSO auth in Debian, I'd like it to happen sooner rather than later. Enrico -- GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini signature.asc Description: PGP signature
ratt as a service?
Hello, ratt (rebuild all the things, https://packages.debian.org/sid/ratt) is really interesting but it's sometimes hard to use effectively on personal resources: some packages have tens, if not hundreds of reverse dependencies, and running ratt for them on your laptop is just not feasible. So i'm wondering if Debian should offer a service where: * a developer (as someone with a gpg key in the debian keyring, at least at first) uploads a binary .changes file (so source + binary packages, built locally) to a new dput upload queue * ratt is executed against that package reverse dependencies * when the run is completed, a recap email is sent to the Changed-By address with the list of fail/success * also a web interface to track the progress of the rebuild & read the build logs. this could be scaled pretty easily with multiple backend "builders" (and we can put limits in place to reduce concurrency, like one package per developer only etc etc) Maybe it's something that could be done as a GSOC project (I'm not volunteering to mentor this project). thoughts? Regards, -- Sandro "morph" Tosi My website: http://sandrotosi.me/ Me at Debian: http://wiki.debian.org/SandroTosi Twitter: https://twitter.com/sandrotosi
Re: ratt as a service?
On Mon, Mar 23, 2020 at 12:34 AM Sandro Tosi wrote: > thoughts? This sounds similar to a couple of other things: The archive testing that Lucas Nussbaum does using donated cloud resources: https://wiki.debian.org/qa.debian.org/ArchiveTesting Luca Falavigna's Deb-o-Matic service: https://debomatic.github.io/ http://debomatic-amd64.debian.net/ http://debomatic-amd64.debian.net/commands -- bye, pabs https://wiki.debian.org/PaulWise
Dependencies on obsolete puppet-common transitional package (potential mass bug filing).
The puppet source package, recently recently dropped the puppet-common binary package. This package has been a transitional dummy package since stretch. Unfortunately there are still a substantial number of packages depending on it. They are listed by maintainer at the end of this mail (the list is based on packages that currently have the issue in bullseye). I filed bugs for the first couple I spotted, but then started to wonder if, given that nearly all of the packages involved are maintained by the openstack team, a more centralised approach is better. If I get no response however I will go ahead with a mass bug filing so the testing autoremoval system can do it's thing. Debian Ruby Extras Maintainers ruby-rspec-puppet Debian OpenStack puppet-module-aboe-chrony puppet-module-antonlindstrom-powerdns puppet-module-aodh puppet-module-arioch-redis puppet-module-barbican puppet-module-ceilometer puppet-module-ceph puppet-module-cinder puppet-module-cloudkitty puppet-module-congress puppet-module-debian-archvsync puppet-module-deric-zookeeper puppet-module-designate puppet-module-glance puppet-module-gnocchi puppet-module-heat puppet-module-heini-wait-for puppet-module-horizon puppet-module-icann-quagga puppet-module-icann-tea puppet-module-ironic puppet-module-joshuabaird-ipaclient puppet-module-keystone puppet-module-magnum puppet-module-manila puppet-module-michaeltchapman-galera puppet-module-murano puppet-module-neutron puppet-module-nova puppet-module-octavia puppet-module-openstack-extras puppet-module-openstacklib puppet-module-oslo puppet-module-ovn puppet-module-panko puppet-module-placement puppet-module-puppetlabs-haproxy puppet-module-puppetlabs-rabbitmq puppet-module-puppetlabs-rsync puppet-module-rodjek-logrotate puppet-module-sahara puppet-module-swift puppet-module-theforeman-dns puppet-module-voxpupuli-alternatives puppet-module-voxpupuli-collectd puppet-module-voxpupuli-corosync puppet-module-voxpupuli-ssh-keygen puppet-module-vswitch PKG OpenStack puppet-module-adrienthebo-filemapper puppet-module-camptocamp-kmod puppet-module-camptocamp-openssl puppet-module-duritong-sysctl puppet-module-nanliu-staging puppet-module-puppetlabs-mongodb puppet-module-puppetlabs-tftp puppet-module-puppetlabs-vcsrepo puppet-module-richardc-datacat puppet-module-saz-rsyslog puppet-module-saz-ssh puppet-module-sbitio-monit Debian OpenStack puppet-module-puppet-community-mcollective
Re: ratt as a service?
> This sounds similar to a couple of other things: hmmm, i'm not sure about that, comments below > The archive testing that Lucas Nussbaum does using donated cloud resources: this is archive-wide and executed seldomly, not on a per-package, on-demand basis > https://wiki.debian.org/qa.debian.org/ArchiveTesting > > Luca Falavigna's Deb-o-Matic service: > > https://debomatic.github.io/ > http://debomatic-amd64.debian.net/ > http://debomatic-amd64.debian.net/commands i dont use this service, but from the documentation it looks like it helps to build a new package, not to test its reverse dependencies after it's built? Regards, -- Sandro "morph" Tosi My website: http://sandrotosi.me/ Me at Debian: http://wiki.debian.org/SandroTosi Twitter: https://twitter.com/sandrotosi
Re: ratt as a service?
On Mon, Mar 23, 2020 at 1:42 AM Sandro Tosi wrote: > hmmm, i'm not sure about that, comments below Sure, neither exactly match right now, but could potentially be tweaked to do what you want. -- bye, pabs https://wiki.debian.org/PaulWise
Re: ratt as a service?
On Mon, Mar 23, 2020 at 8:34 AM Sandro Tosi wrote: > > Hello, > ratt (rebuild all the things, https://packages.debian.org/sid/ratt) is > really interesting but it's sometimes hard to use effectively on > personal resources: some packages have tens, if not hundreds of > reverse dependencies, and running ratt for them on your laptop is just > not feasible. > > So i'm wondering if Debian should offer a service where: > > * a developer (as someone with a gpg key in the debian keyring, at > least at first) uploads a binary .changes file (so source + binary > packages, built locally) to a new dput upload queue > * ratt is executed against that package reverse dependencies > * when the run is completed, a recap email is sent to the Changed-By > address with the list of fail/success > * also a web interface to track the progress of the rebuild & read the > build logs. > > this could be scaled pretty easily with multiple backend "builders" > (and we can put limits in place to reduce concurrency, like one > package per developer only etc etc) This is especially useful for some teams, like pkg-go team. Most ftbfs can't be found except rebuilding all the reverse dependecies. This is probably why stapelberg implemented this. If there's a such service, I hope it can be integrated with salsa, and be triggered when you push. However if it's been widely used, I would concern how to build more efficiently and cache friendly. -- Shengjing Zhu
Re: MBF? ftbs
On 22/03/20 at 20:32 +0100, Adam Borowski wrote: > Hi! > There's a bunch of packages that fail to repack their sources. That is, > "dpkg-buildpackage -S" fails in a clean environment. > > I've tested the entire archive, invoking: > sbuild -s --source-only-changes --no-arch-all --no-arch-any > > The list below includes all packages which fail the repack but don't FTBFS > on a binary-only build (on amd64). > > I wonder what would be the appropriate severity: the Policy is clear, but no > one filing bugs for failure to repack suggests it's nowhere bad enough to > brandish the RC stick. Hi, If it's considered severity: serious, I could add this to my archive rebuilds to detect future regressions. However, in several cases, it seems that the problem is that sbuild does not install packages in Build-Depends-Indep when doing a source-only build, and then fails when doing 'debian/rules clean'. I wonder if that should be fixed in sbuild. Lucas
