Work-needing packages report for Jan 19, 2018
The following is a listing of packages for which help has been requested through the WNPP (Work-Needing and Prospective Packages) system in the last week. Total number of orphaned packages: 1165 (new: 3) Total number of packages offered up for adoption: 150 (new: 2) Total number of packages requested help for: 50 (new: 0) Please refer to http://www.debian.org/devel/wnpp/ for more information. The following packages have been orphaned: backuppc (#887490), orphaned yesterday Description: high-performance, enterprise-grade system for backing up PCs Installations reported by Popcon: 1023 Bug Report URL: http://bugs.debian.org/887490 libbackuppc-xs-perl (#887491), orphaned yesterday Installations reported by Popcon: 8 Bug Report URL: http://bugs.debian.org/887491 logrotate (#887151), orphaned 4 days ago Description: Log rotation utility Reverse Depends: aolserver4-daemon apertium-apy argus-server battery-stats clamav-base clamav-freshclam clamav-milter davmail ippl knockd (21 more omitted) Installations reported by Popcon: 200415 Bug Report URL: http://bugs.debian.org/887151 1162 older packages have been omitted from this listing, see http://www.debian.org/devel/wnpp/orphaned for a complete list. The following packages have been given up for adoption: bluefish (#887145), offered 4 days ago Description: advanced Gtk+ text editor for web and software development Reverse Depends: bluefish Installations reported by Popcon: 3899 Bug Report URL: http://bugs.debian.org/887145 html-xml-utils (#887146), offered 4 days ago Description: HTML and XML manipulation utilities Reverse Depends: haskell-devscripts-minimal Installations reported by Popcon: 886 Bug Report URL: http://bugs.debian.org/887146 148 older packages have been omitted from this listing, see http://www.debian.org/devel/wnpp/rfa_bypackage for a complete list. For the following packages help is requested: autopkgtest (#846328), requested 414 days ago Description: automatic as-installed testing for Debian packages Reverse Depends: debci-worker openstack-pkg-tools Installations reported by Popcon: 1082 Bug Report URL: http://bugs.debian.org/846328 balsa (#642906), requested 2307 days ago Description: An e-mail client for GNOME Installations reported by Popcon: 673 Bug Report URL: http://bugs.debian.org/642906 broadcom-sta (#886599), requested 10 days ago (non-free) Description: Broadcom STA Wireless driver (non-free) Installations reported by Popcon: 1975 Bug Report URL: http://bugs.debian.org/886599 cargo (#860116), requested 282 days ago Description: Rust package manager Reverse Depends: dh-cargo Installations reported by Popcon: 563 Bug Report URL: http://bugs.debian.org/860116 cups (#532097), requested 3148 days ago Description: Common UNIX Printing System Reverse Depends: ayatana-indicator-printers bluez-cups boomaga chromium cinnamon-settings-daemon cloudprint cups cups-backend-bjnp cups-browsed cups-bsd (69 more omitted) Installations reported by Popcon: 177698 Bug Report URL: http://bugs.debian.org/532097 cyrus-sasl2 (#799864), requested 848 days ago Description: authentication abstraction library Reverse Depends: 389-ds-base 389-ds-base-libs 389-dsgw adcli autofs-ldap cairo-dock-mail-plug-in claws-mail claws-mail-acpi-notifier claws-mail-address-keeper claws-mail-archiver-plugin (124 more omitted) Installations reported by Popcon: 199387 Bug Report URL: http://bugs.debian.org/799864 dee (#831388), requested 552 days ago Description: model to synchronize mutiple instances over DBus Reverse Depends: dee-tools gir1.2-dee-1.0 libdee-1.0-4-dbg libdee-dev zeitgeist-core Installations reported by Popcon: 63745 Bug Report URL: http://bugs.debian.org/831388 developers-reference (#759995), requested 1237 days ago Description: guidelines and information for Debian developers Installations reported by Popcon: 14596 Bug Report URL: http://bugs.debian.org/759995 devscripts (#800413), requested 842 days ago Description: scripts to make the life of a Debian Package maintainer easier Reverse Depends: apt-build apt-listdifferences aptfs arriero brz-debian bzr-builddeb customdeb debci debian-builder debmake (27 more omitted) Installations reported by Popcon: 13073 Bug Report URL: http://bugs.debian.org/800413 ed (#886643), requested 10 days ago Description: classic UNIX line editor Reverse Depends: apt-cacher debbugs opensmtpd sn Installa
Bug#887675: ITP: vala-panel -- Desktop panel written in Vala and GTK+ 3
Package: wnpp Severity: wishlist Owner: Mike Gabriel * Package name: vala-panel Version : 0.3.71 Upstream Author : Konstantin P. * URL : https://github.com/rilian-la-te/vala-panel * License : GPL-2+, LGPL-2.1+ Programming Lang: Vala Description : Desktop panel written in Vala and GTK+ 3 Vala Panel is a rewrite of SimplePanel. It is a GTK+ 3 desktop panel written in Vala and based on ideas from LXPanel. . Vala Panel can be extended with plugins that provide application menus, clock, tasklist, system tray, etc. . This package will be maintained under the umbrella of the Ayatana Packagers and the Debian+Ubuntu MATE Packaging Team.
Bug#886238: Build-Profiles purpose, mechanism vs policy (was Re: Bug#886238: Please introduce official nosystemd build profile)
On 18/01/18 21:50, Adrian Bunk wrote: > On Thu, Jan 18, 2018 at 06:52:57PM +0100, Emilio Pozuelo Monfort wrote: >> On 10/01/18 01:29, Sam Hartman wrote: >>> A build profile seems like a great way to express the flag, and like >>> many things in Debian, the work would fall on those who would benefit >>> from it. >> >> I think it'd be better to be able to mark a build-dependency as optional, and >> then implement a mechanism in dpkg to disable the undesired >> build-dependencies. >> E.g. if packages start marking libselinux-dev as , with autoconf or >> similar automatically disabling selinux support when not present, then a user >> could build the package with something like dpkg-buildpackage >> --disable-optional=libselinux-dev. This way we don't need a different build >> profile for each build-dep and package, which would end up in a mess. Of >> course >> we need to change the above syntax to not clash with build profiles, and add >> DEB_BUILD_OPTIONS support, but you get the point I hope. Seems a lot more >> standard to me than having each package define its own profiles for each >> optional dependency. > > When the sole purpose of a rebuild is to get rid of unused library(ies), > the rebuild only makes sense if this is supported throughout the whole > distribution. > > The problematic cases are the non-trivial ones, > and what support Debian wants to provide for that. > > It would make the life for the Devuan people much easier if Debian > would be committed to have *all* packages in buster build and work > with --disable-optional=libsystemd-dev. > > Are you as release manager willing to make this a supported feature > for buster, with breakages being RC bugs? > > For small embedded systems, having this only for one library > doesn't bring that many benefits. > > For how many libraries are you release manager willing to make > --disable-optional a supported feature for buster, with breakages > being RC bugs? Nothing of this sort is going to be RC, no matter if we implement it via build profiles or by some other mechanism. I'm not even sure we need it. My only point is that if we are going to start adding this for every optional feature as it was being suggested, we should do it properly and not abusing build profiles. Cheers, Emilio
Bug#886238: Build-Profiles purpose, mechanism vs policy (was Re: Bug#886238: Please introduce official nosystemd build profile)
On Thu, Jan 18, 2018 at 06:52:57PM +0100, Emilio Pozuelo Monfort wrote: > On 10/01/18 01:29, Sam Hartman wrote: > > A build profile seems like a great way to express the flag, and like > > many things in Debian, the work would fall on those who would benefit > > from it. > > I think it'd be better to be able to mark a build-dependency as optional, and > then implement a mechanism in dpkg to disable the undesired > build-dependencies. > E.g. if packages start marking libselinux-dev as , with autoconf or > similar automatically disabling selinux support when not present, then a user > could build the package with something like dpkg-buildpackage > --disable-optional=libselinux-dev. This way we don't need a different build > profile for each build-dep and package, which would end up in a mess. Of > course > we need to change the above syntax to not clash with build profiles, and add > DEB_BUILD_OPTIONS support, but you get the point I hope. Seems a lot more > standard to me than having each package define its own profiles for each > optional dependency. When the sole purpose of a rebuild is to get rid of unused library(ies), the rebuild only makes sense if this is supported throughout the whole distribution. The problematic cases are the non-trivial ones, and what support Debian wants to provide for that. It would make the life for the Devuan people much easier if Debian would be committed to have *all* packages in buster build and work with --disable-optional=libsystemd-dev. Are you as release manager willing to make this a supported feature for buster, with breakages being RC bugs? For small embedded systems, having this only for one library doesn't bring that many benefits. For how many libraries are you release manager willing to make --disable-optional a supported feature for buster, with breakages being RC bugs? It is really important to look at it top-down from what Debian wants to officially support in the end - these technical details only matter if Debian will officially support rebuilding the whole archive of a stable release with fewer libraries. > Cheers, > Emilio cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed
Re: udftools, pktsetup and init scripts
On Wednesday 17 January 2018 18:07:59 Pali Rohár wrote: > Ok, that you for opinion. I drop init script and include upstream udev > rule which replace it. And because there is no feature request for > splitting package into more, I let it as is to not complicate it. Updated package is there: https://mentors.debian.net/package/udftools -- Pali Rohár pali.ro...@gmail.com signature.asc Description: PGP signature
Bug#886238: Build-Profiles purpose, mechanism vs policy (was Re: Bug#886238: Please introduce official nosystemd build profile)
On Thu, 18 Jan 2018, Emilio Pozuelo Monfort wrote: > I think it'd be better to be able to mark a build-dependency as > optional, and then implement a mechanism in dpkg to disable the > undesired build-dependencies. Someone who was interested could get part way to this by running builds with an empty equivs package which satisfied the build-dependency. That could help give the involved parties (which does not include me) an idea of whether implementing such a feature was a worthwhile expenditure of their energy. -- Don Armstrong https://www.donarmstrong.com He no longer wished to be dead. At the same time, it cannot be said that he was glad to be alive. But at least he did not resent it. He was alive, and the stubbornness of this fact had little by little begun to fascinate him -- as if he had managed to outlive himself, as if he were somehow living a posthumous life. -- Paul Auster _City of Glass_
Bug#886238: Build-Profiles purpose, mechanism vs policy (was Re: Bug#886238: Please introduce official nosystemd build profile)
On 10/01/18 01:29, Sam Hartman wrote: > A build profile seems like a great way to express the flag, and like > many things in Debian, the work would fall on those who would benefit > from it. I think it'd be better to be able to mark a build-dependency as optional, and then implement a mechanism in dpkg to disable the undesired build-dependencies. E.g. if packages start marking libselinux-dev as , with autoconf or similar automatically disabling selinux support when not present, then a user could build the package with something like dpkg-buildpackage --disable-optional=libselinux-dev. This way we don't need a different build profile for each build-dep and package, which would end up in a mess. Of course we need to change the above syntax to not clash with build profiles, and add DEB_BUILD_OPTIONS support, but you get the point I hope. Seems a lot more standard to me than having each package define its own profiles for each optional dependency. Cheers, Emilio
Re: Why do we list individual copyright holders?
Matt Zagrabelny writes ("Re: Why do we list individual copyright holders?"):
> On Tue, Jan 16, 2018 at 10:53 AM, Ian Jackson
>
> wrote:
>
> But I'm a hardy soul who is quite prepared to see a warning and decide
> to ignore it :-).
>
> My view is that the purpose of a warning is to alert you to something,
> so you can decide what to do about it.
>
> What is the difference between "warn" and "info", then?
What I wrote above applies to most if not all messages from lintian,
even "error". The severities help a contributor to prioritise if they
have only a limited amount of time to spend on polishing, or need to
do an upload in a hurry (eg a security update), or something.
Ian.
--
Ian JacksonThese opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
Re: Default page view for salsa repositories
On Thu, 18 Jan 2018, Arturo Borrero Gonzalez wrote: > On 18 January 2018 at 11:15, Alex Mestiashvili > wrote: > > Hi All, > > > > while browsing through salsa.debian.org packages I got a feeling that > > displaying upstream's Readme by default is not exactly relevant to > > Debian packages. I guess it would make more sense do display > > d/Readme.source if available or d/changelog instead. > > Or even something more advanced like tracker.debian.org for a package... > > A repository owner should be able to override this setting of course. > > > > +1 Feel free to create an upstream issue asking for such a setting. Alex
Bug#887598: ITP: jasp -- Offers standard analysis procedures in both their classical and Bayesian form
Package: wnpp Severity: wishlist Owner: Joris Goosen X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: jasp Version : 0.8.5 Upstream Author : JASP-team * URL : http://www.jasp-stats.org/ * License : GPL Programming Lang: C++, R Description : Offers standard analysis procedures in both their classical and Bayesian form JASP is a cross platform statistical software program with a state-of-the-art graphical user interface. It offers standard analysis procedures in both their classical and Bayesian form. . It was designed with the user in mind: APA-formatted tables can be copy-pasted in your word processor, output can be extensively annotated, adjustment of input options dynamically changes the output, and selecting old output revives the associated input choices for inspection and adjustment. . JASP is also statistically inclusive, as it offers both frequentist and Bayesian analysis methods. Indeed, the primary motivation for JASP is to make it easier for statistical practitioners to conduct Bayesian analyses. . For more information and tutorials see: https://jasp-stats.org/ This package is useful as it allows scientist, especially in the social sciences, a friendly interface to state-of-the-art statistics techniques and is under active development. I plan to maintain as part of my work as one of the upstream-developers and aim to make it fully debian compatible from the get-go. As far as i've understood the information on the debian-wiki we will need a sponsor to be able to upload to the debian repositories.
Re: Default page view for salsa repositories
On 18 January 2018 at 11:15, Alex Mestiashvili wrote: > Hi All, > > while browsing through salsa.debian.org packages I got a feeling that > displaying upstream's Readme by default is not exactly relevant to > Debian packages. I guess it would make more sense do display > d/Readme.source if available or d/changelog instead. > Or even something more advanced like tracker.debian.org for a package... > A repository owner should be able to override this setting of course. > +1
Default page view for salsa repositories
Hi All, while browsing through salsa.debian.org packages I got a feeling that displaying upstream's Readme by default is not exactly relevant to Debian packages. I guess it would make more sense do display d/Readme.source if available or d/changelog instead. Or even something more advanced like tracker.debian.org for a package... A repository owner should be able to override this setting of course.
