Re: mtkbabel mayby unmaintained long time new version available Perl? advice?
benatt...@gezapig.nl writes: > Hello, > I think mtkbabel is unmaintained. > Listed maintainer Uwe Hermann > (https://qa.debian.org/developer.php?email=uwe%40debian.org) > There is a new version since oct-2019 with some improvements. > I am no maintainer no coder etc. Probably I will never sent paches etc. > What is the best I could do in such cases. > Is there some kind of template that I could use when contacting > the maintainer directly. > And would it be appreciated when cc ing teams in this case maybe Debian Perl > Group? > Thanks. It's great that you want to help Debian, but I'm sorry to say your current bug filing strategy is not (in my opinion as an individual maintainer) very helpful. It seems like the bugs you are filing mostly duplicate the information already in tracker.debian.org. If you are a user of the software in question, then it's reasonable to file a wishlist bug asking for an update, or higher severity bugs for specific issues fixed in the new version. Otherwise you are just adding noise, and probably increasing the stress level of overworked volunteers. As a non-developer, there is still plenty you can do in terms of triaging existing bugs (seeing if they can be duplicated on your system), and reporting actual (major or minor) problems with the software you are using. I hope you will consider this as constructive feedback. David
Re: Any way to install packages+run autopkgtests on porterbox machines?
Nilesh Patra writes: > When I want to fix autopkgtests for a package on a particular architecture, I > currently > see no way to run autopkgtests before I dput since porter boxes do not > provide root > access which autopkgtest needs. > > Currently I am manually hacking around the test scripts and running the > autopkgtests but > this does not emulate the autopkgtest environment well enough. It also does > not work > well for daemon-like packages for instance. Related, we wouldn't need to use the porterboxes if the situation for running autopkgtests locally was better. I have complained at length on IRC on the difficulties of running autopkgtests locally on non-amd64 architectures. There is some tooling to build images for e.g. the qemu backend, but in my experience it does not work smoothly. I think the autopkgtest maintainers could use help with improving this tooling. Personally I am reluctant to add non-amd64 autopkgtests to packages with the current state of tooling. I do not consider "upload and find out" an acceptable debugging strategy.
Re: Bug#1053165: ITS: nunit
Bastian Germann writes: > Source: nunit > > I intend to salvage nunit with the plan to orphan it in three weeks. > Please notify me if you object. In my opinion, your repeated "salvaging" of packages in order to orphan them is an abuse of the ITS process. Yes, it's a clever procedural hack, but Debian is not (supposed to be) about tricking our fellow developers. I don't know what best process to do the QA work you want to do is; I suspect you should consult the MIA team for suggestions. David - who co-wrote the ITS process, and knows what it says.
Re: solanum package request
Joaquín Rufo Gutierrez writes: > Hello!!! > I need to request solanum package from: > https://github.com/solanum-ircd/solanum > I will wait for the response. > Thank you There is already a "Request for package", but no progress in 10 months. You follow by subscribing to the bug on this page https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1017744
Bug#1031167: ITP: elpa-gap-mode -- modes for editing GAP programs and running a GAP session in Emacs
Package: wnpp Severity: wishlist Owner: David Bremner X-Debbugs-Cc: debian-devel@lists.debian.org, debian-emac...@lists.debian.org -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 * Package name: elpa-gap-mode Version : 2.1.0 Upstream Contact: Ivan Andrus * URL : https://gitlab.com/gvol/gap-mode * License : MIT Programming Lang: emacs-lisp Description : modes for editing GAP programs and running a GAP session in Emacs Long description to follow. If you use GAP [1] and Emacs, you know what this is. This will be maintain within the Emacs addons team. There is a repo on salsa [2] for the curious. [1]: the one at https://www.gap-system.org, packaged as "gap" in Debian. [2]: https://salsa.debian.org/emacsen-team/gap-mode -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEEkiyHYXwaY0SiY6fqA0U5G1WqFSEFAmPpHA8ACgkQA0U5G1Wq FSHvRQ/8DbJlkTemj7a6UIiHyzY6YUGMpDX2F/dF6iDOi5vc3iqWTtj5r++SxMg3 e44WgMqT8ay1mvPAm3qZaCoTpkMKqGUTn4tH5osBV6wmHApwtRsq+Q7TY9Q/V/Go OI76dhR8E8iBceUBULXyLdKoEfg6KpI/qSA9xpuUTzde+jFvZ5Rh8tDAg0E8gDzM Z34ixN4MKeDEAu/36wERtOkC70ruV4Dpi9irzOdeKo8W7KvL7324hc0beOB2sX6I kSb7a+AHgb9LdT/mtQ2KqMl0M0oLRNhIVSmR7gc39KpZLfHqWzehHSqOgStR2iFR E0y1Ld5vAsVbnRRFc9TmATlA6ztLTqv3IpnxKGX21UkrOM8bRw36RUnKuzJFP22a NMY5qmJaI5+Wef1Lt2kK5r8SLl1hn6FeRwSaywEKc+GndrIOMoqM2knl/ghCFVxD Iww3lWdwO/xZ4944+L4es6EZPpEAskP0KIoFbESf9yBO5aoAyAWR2zr5fdezoRqe e90L200GZKAoH5h4sbIju4JGdUxqY8jczexHuluGvQOwVoTQn93qMCDKyoc9eWf/ 0jhifVFZyjlmcrS8IjVZ81Sqdi6/q21MZt2vERy6vN0xZSPBIWsZpZrjXbl6l9TE X7wdcaWNec/yhLxQf4GiDFVC7fm7ssDyLoeJOE0mBh0NPJvy4Ro= =u+GY -END PGP SIGNATURE-
Bug#1024362: ITP: elpa-ol-notmuch -- Emacs org-mode links to notmuch messages and searches
Package: wnpp Severity: wishlist Owner: David Bremner X-Debbugs-Cc: debian-devel@lists.debian.org, debian-emac...@lists.debian.org * Package name: elpa-ol-notmuch Version : 2.0.0 Upstream Author (Maintainer) : Jonas Bernoulli * URL : https://git.sr.ht/~tarsius/ol-notmuch/ * License : GPL3+ Programming Lang: Emacs lisp Description : Emacs org-mode links to notmuch messages and searches This functionality was split from elpa-org-contrib. I plan to maintain it with the Debian Emacsen team
Bug#1022114: RFH: highlight -- Universal source code to formatted text converter
Package: wnpp Severity: normal X-Debbugs-Cc: debian-devel@lists.debian.org Control: affects -1 src:highlight -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 I request assistance with maintaining the highlight package. I have not really been keeping up with new upstream releases and could use a co-maintainer. The package description is: A utility that converts sourcecode to HTML, XHTML, RTF, LaTeX, TeX, SVG, XML or terminal escape sequences with syntax highlighting. It supports several programming and markup languages. Language descriptions are configurable and support regular expressions. The utility offers indentation and reformatting capabilities. It is easily possible to create new language definitions and colour themes. -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEEkiyHYXwaY0SiY6fqA0U5G1WqFSEFAmNRIyoACgkQA0U5G1Wq FSGyjQ/8CbUEHtTj0Rad0xZAdVULj9B3EqJN9H35YyUatq85rbdJ69p1cMLgWiu0 hQbypoCRyn+swf30+Slc7X8tIlmKoqxkDJOiqGl5uLdgEUmMB5Ael89ZUCQU+yh5 m2BPAYWb6AuU0uJPPXBGIfIcw54ZtzzGMarvgd7PTlxEOYBaSZo+mkzO4YB/AoXc xLSSXUp8mW3kqQoQEtyJ5NlwfFVoaERUIJcJXHurtd3wWk8NCbqau+10/m/oyem8 AzRHzEzu8FsIadYlK6jyvCtcuHY6WwEVnA++qsWd92CjBza2nmb2bjS8bgRRC/JS K/gcK2bf2zA2J4o6BKJgfSmTO9rzp0hb4CwYv/91ecM/rNB8mBvUIYzZn1caKbGZ N758k9HcyMDywEdZ8Ue2fl0hmYg0/skO7FJEB2TIfnAhqJlQ6n+MexRLIVTAJ8zW 1omcULUhnW3c6IdK8WmM6DuX76iO1QGkrslMU3opsKvy8G4jOyp8l3qh3oqd6uWj hXknT5lPaE936qd6xDn2dy4niB07W0FhSWBpb9jb3nb5G1pkoWbx/iRjmRT+v0KU QB50EoNYZDVWw9AyI0wTkU3NwanWWIggG6lpripCoirxaqlDkkJxe5VH0N9fZncZ irLYONNifkBHonshPaDgIYGTN5U55NlaVPs58p95GGvNw+61dmg= =GkDM -END PGP SIGNATURE-
Bug#1019205: ITP: elpa-srv -- RFC2782 (SRV record) client for emacs
Package: wnpp Severity: wishlist Owner: David Bremner X-Debbugs-Cc: debian-devel@lists.debian.org, debian-emac...@lists.debian.org -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 * Package name: elpa-srv Version : 0.2 Upstream Author : Magnus Henoch * URL : https://github.com/legoscia/srv.el * License : GPL2+ Programming Lang: Emacs lisp Description : RFC2782 (SRV record) client for emacs This package is used to look up hostname and port for a service at a specific domain. There might be multiple results, and the caller is supposed to attempt to connect to each hostname+port in turn. This is a dependency of recent versions of elpa-jabber (and indirectly a blocker for an RC bug fix). It will be managed by the Emacs Addons team. -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEEkiyHYXwaY0SiY6fqA0U5G1WqFSEFAmMV/40ACgkQA0U5G1Wq FSHuVxAAr/u1BTMh9LNrqYnoEY3vdnxNGRWhtX90BXtXYEGYSpEsrFYis/L4SGqN FCGDTj/wd7ItRgfAEVJliuX/DfbNrBgLDjbV12JBbQeERK4jKfa2HpjQ3Q0XntLK z6FwOnRuux9Ue17AT/k+WsgIzmd47WSCDfFCBWofO8JVOvZmM07W4ynr8vHlrOkC LUNcMuKma8gNdSYw90oxWrJPpQFIsN6O/A1CKmrXyD/TmdbxsC45Rou1w1TnjHck GrqQf7I0DCClhEmp/6XH6aWEFqdYAL5OFX8XUxEY0sXf6OGY0IOr4VkiOa6JWsvb iPdb75Bz/XIP6KkeLg0nNXOnXiW3Qwm9Sa2ex9kwBYtpF1ZSw/+WEPnQb1xq9bYs xI5gRpjx3VSOXkKAMiulzDM4Q6KbJTbu1kxbk++6O15R9cNzuUwk/U0GsMRnYJWh f8jW4L4APbmmf5hDmW4yCFlXdxxhCUe2Nv2XvfgLjfdDxFpb+4aIi2GWqDEvdWRO tKeI4aznKQnejYlpy1YIuU3oH1QG4RRspF/HpuGc0gH1qtRmrN7RQy+z6OeWZQFS ROQyPTSiy3dBlSNHKiFu/fk+0MRbSQPK9w+gLwz76o+f874V1M8vlIrf47PsXGeU eb87I27dgDw1w3S3f+kDIQDgjfqm2MsUdWyi65ki30h+QvLS0AE= =FQbh -END PGP SIGNATURE-
Re: A mail relay server for Debian Members is live
Bastien Roucariès writes: > Le samedi 16 juillet 2022, 21:49:31 UTC Pierre-Elliott Bécue a écrit : > Thanks for this hard work, however it seems that some mail client consider > these mail as invalid, whereas gmail and other verifier service consider ok... > > Any idea for debugging? > > Bastien Hi Bastien; I'm not involved with the service (even as a user), but I am interested in mail clients. Can you be more specific about what is failing and on what client? A sample message is typically needed to debug these things. I'm not sure there is any sensible way to report issues (RT? BTS?) but if someone knows, that would be useful to mention. d
Re: libxslt: some CVEs not fixed in debian buster
Akira Shibakawa writes: > CVE-2019-5815 and CVE-2021-30560 are vulnerabilities of libxslt > included in chromium source code as third-party code. > And not only chromium but also libxslt upstream has already fixed them. > https://gitlab.gnome.org/GNOME/libxslt/-/commit/08b62c258 > https://gitlab.gnome.org/GNOME/libxslt/-/commit/50f9c9cd3 > > Because libxslt in debian buster is older than the fixed version in > upstream, these bugs are still present in debian buster. > Is there any plans to fix them in debian buster ? > (I am wonder why these CVEs are linked to only chromium, not libxslt.) Since security support for buster will expire in a few days, I suggest following up with the LTS team. More information is available at https://wiki.debian.org/LTS signature.asc Description: PGP signature
Re: Reminder to participate in the Debian Developer's Survey
Utkarsh Gupta writes: > A couple of days back we had invited all the Debian Developers to > participate in a survey[1] about the usage of money in Debian that > we discussed[2] a couple of months back on debian-project@l.d.o. > > This is just a follow-up reminder to the same. So far we've roughly > 140 DD participants who signed up and roughly 100 who have completed > the survey. We're hoping to reach 200-300 participants (close > to what we get for a GR), so please take the 15-25 minutes required > to fill out the survey. For the record, I gave up on the survey about half way through because it refused to let me advance without giving an answer to one of the questions. Consider this feedback on the survey design. signature.asc Description: PGP signature
Re: Unified workflow for package review
Raphael Hertzog writes: > > I fully expect such a service to have an API that can be used to build > a command line interface for people like you. Yep, but I already don't use the various things like that for e.g. salsa or github because it's too much hassle to set up for too little benefit. Similarly my experience with the "addon email workflows" for web based tools is that (as second class citizens) they typically don't quite work right. > At the same time, we must recognize that our aging email-based workflows > and the multitude of different workflows are hurting our ability to > on-board new contributors. Fair enough. Every tooling choice involves tradeoffs. We just have to be mindful and honest about the friction created for existing contributors by reducing it for new contributors. I think it's easy to underestimate other peoples difficulties/annoyances with the workflow that we are used to. So for people immersed in github or gitlab, this seems like the natural and obvious way to work, just like for (some) people immersed in email workflows those seem natural and obvious.
Re: Unified workflow for package review
Raphael Hertzog writes: > We should have a single web service that is able to handle all those > workflows and provide all the inputs that each team needs to make their > decision. It should have a nifty web interface (including with > authentication and restricted access for embargoed security updates) where > people can inspect the packages and approve/reject the packages if they > are part of the affected teams. > I know that many people would like more web interfaces, but if I _have_ to use a web service to do my packaging work, I will stop. No accounting for taste I guess. d
Re: etc/resolvconf/update-libc.d/ equivalent for systemd-resolved
Scott Kitterman writes: > I believe I can solve this problem by adding Recommends: resolvconf if that's > the only way. I had hoped there would be some "modern" way to do it from > within Debian's default package set. I hope that wouldn't interfere with an enabled systemd-resolved, otherwise that seems likely to cause some breakage. d
Bug#990684: ITP: sfsexp -- small fast s-expression library
Package: wnpp Severity: wishlist Owner: David Bremner X-Debbugs-Cc: debian-devel@lists.debian.org -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 * Package name: sfsexp Version : 1.3.1 Upstream Author : Matthew Sottile * URL : https://github.com/mjsottile/sfsexp * License : LGPL2.1+ Programming Lang: C Description : small fast s-expression library This library is intended for developers who wish to manipulate (read, parse, modify, and create) symbolic expressions (s-expressions) from C or C++ programs. I did not find a library with equivalent footprint and functionality in Debian. -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEEkiyHYXwaY0SiY6fqA0U5G1WqFSEFAmDh9j8ACgkQA0U5G1Wq FSH88A/+MF/IrmVmvsvHsylcbTCwvtypdkS/G1EKuOpp1nBblq57yan3VuFJi2JY +f5DsOvutkE9dnDaCe4jWgN4ZBvngHLzReDj2ITHgRSxTIyQ+8zSu/6fVkQiqnqn RcA7tTvi6CaUDNF1CKAnbpmaxgtJwt77R7kqq3AFt4cWrVFLJCReTo/4pqDsGIzF 1Z8L4c6VmhVqObfoMQ/lGAjw4vpJyod7vCbt5XOPyf/yb7VBuIWneUrJv07WVznF 5fVTj4/AEDw4osKrBnBviAgmS6FdVaSSu/Cn0ODBf3ZSKiQGrJH4qHFk5MtBJaA1 aRfsKEmkhCU1jARdJM/kI87fLHV3oOShyJcUSOiZ5PnescAhL0ovO3mv8H1+kaBZ iclVDN7r40cZfDgrxpX8A9SL6UOT0Sssxbi6IaH35Aj+/DYFjpL1Xo+VGPyezvZ+ +tHAPKAHyIzP6Bl0+vlEFR5B3RFHuhG8789FWUp/n/g5M1fxVKdbEqzNz/JxFb5H OdSa29izQrNv4OcfVhDE2ZWwBh/hnQoM+FwPYrM3jreEy7VxurN8+8GR5jJoK1gB H1AVayAxyrA+ycs0r0RQBv491+FeX7wNPHjYhbjZP0nOiDl4NZy3EtS7N0NmQHeC Ih2xSmTkhWiFeVsVvPR37eYMVdd+Sl7dU/lsxDVFQ4VFuaFdIpI= =PzAS -END PGP SIGNATURE-
Re: Would you please share me any information about which version of Debian supports NVDIMM？
Yuhua Zou writes: > I assume Debian have supported NVDIMM from the following links: > https://lists.debian.org/debian-devel/2016/12/msg00330.html > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=829257 > > I can install package “ndctl” in Debian 10.9. > > I explored Debian wiki but couldn't find any information about which versions > are supporting NVDIMM. > If anyone can share with me any information about which versions of Debian > support NVDIMM. I would appreciate it. I can confirm support for (Dell) NVDIMM in Debian 11, but that's about all I know from experience. d
Re: Epoch bump for kernelshark
Mattia Rizzolo writes: > On Sun, May 23, 2021 at 03:17:10PM -0500, Richard Laager wrote: >> On 5/23/21 8:34 AM, Sudip Mukherjee wrote: >> > And, as a result, upstream kernelshark is now at v2.0 but the Debian >> > packaged version is at v2.9.1 and I will need to add an epoch to the >> > version to package it directly from its new upstream repo. >> > >> > Current version: 2.9.1-1 >> > Proposed version: 1:2.0-1 >> >> How close is upstream to 3.0? If not close, are they willing to bump to 3.0 >> anyway to avoid this versioning issue? > > And in the meantime, I recommend you use 2.0-1 as source version, and > make the binary 2.9.1+really$(DEB_VERSION) (DEB_VERSION coming from > /usr/share/dpkg/pkg-info.mk) > _If_ upstream is willing to do that, then great. Otherwise I don't see the problem with an epoch in this kind of situation. It's exactly the kind of change of versioning they were designed for. d
Bug#987150: ITP: sfsexp -- small and fast s-expression parsing library
Package: wnpp Severity: wishlist Owner: David Bremner X-Debbugs-Cc: debian-devel@lists.debian.org -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 * Package name: sfsexp Version : 1.3 Upstream Author : Matthew Sottile * URL : https://github.com/mjsottile/sfsexp/ * License : LGPL Programming Lang: C Description : small and fast s-expression parsing library This library is intended for developers who wish to manipulate (read, parse, modify, and create) LISP-style symbolic expressions from C or C++ programs. This seems to be one of those things that is re-invented many times. I'm not 100% committed to packaging this yet, but I have some work in progress at https://salsa.debian.org/bremner/sfsexp One question is whether to follow upstream and name the library / binary package as libsexp(n) or if that is too generic. -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEEkiyHYXwaY0SiY6fqA0U5G1WqFSEFAmB8IT4ACgkQA0U5G1Wq FSHvpBAAin7Vu6ranMIhYdLTWy/xW6Hkoi1vvhyahuWsbLC5d58KlWvuUGZpUrFy KAtjFLWSG5iVUltAtb6b4/ZWkQ5eTLKYhXfyv3iw9O/Pj8NqgTnp8LFxA84Kc5ND Gs259CXWGtpvE5YTnayfbcxi82ZE/xyhjNDv4YDp2GA3CF3BGlFl7nBAhtFDpyV7 AahWtdkJkrkV0zUCEXiFcgS32y0fsMREeuOfKFowpCIW703v1mBSZuFojJlfFhTE Ure9XfAs9++9Ra70xDzyprg7SPr6lG6Fd+cNEiUNubn6CFTvCMPI0fYZGW05Hq/z vVR1Jqk8pqchoB8DyKXE11PLW6dRtFZtl3r7rGZVDLs+dx/T/O4/dlgbQXIfFXVd ye0SavbTgfwEJm9YZV5G4MLnzm1oY6TVsLFMlRozJIE7GZd+pgCFJFwPc2W9DMn7 5voWYOxP1p2d8nAXVBFle7QbcrxBi8BgxGTjQSUepJb3mDHZd30D4K3LpaHELYpf Y03MgGt2Pm0ekXRTqddvJBzNI821VAemuXroEkD+loyWe+nO2a7zfJUcC/PNykvg Y/Dy2DzgadA9JcrlyibNQ64Oadu96qZZifj2ZmUePbETqRIYAEKJGhlXBWrx4ADR oacsndxa3lkYznFJSYrU+AN9jQbb3cOPx8nLWmdmgA2Vzo+dKes= =S9oZ -END PGP SIGNATURE-
Re: Fixed release dates are hurting quality
John Paul Adrian Glaubitz writes: > It shouldn't be enough for a package to have its worst bugs fixed like FTBFS > or > crashes when it gets shipped with a release. Packages that are being shipped > with > a release should also be properly maintained or not shipped at all. For context, there are currently 929 packages maintained by packa...@qa.debian.org. That doesn't count packages that have an inactive maintainer, which is more challenging to quantify.
Re: Mass bugs filing: autopkgtest should be marked superficial
Paul Gevers writes: > > Notwithstanding the wording, the Release Team is happy with the bugs > that Sudip is filing. Because of the way that autopkgtests are used in > the Debian infrastructure to influence migration from unstable to > testing [1], it is very important that autopkgtests are recognized for > what they are. If an autopkgtest isn't really testing the installed > binaries (and yes, the boundary is unfortunately not well defined) it's > crucial that the test is marked as superficial, conform our rc_policy > [2]. The Release Team has decided that the examples that Sudip tagged, > i.e. --version, --help, checking for some installed file and the Python > import check, are superficial. OK, that's all very well, I understand the release team needs to do things for its own needs. However 1) Such an autopkgtest would have prevented an actual RC (as in makes the package unusable) bug in a recent upload of ledger 2) I'm now even less motivated to add autopkgtests. So, there can, and will be unintended consequences. Maybe that's an acceptable tradeoff, I don't know. Don't, as they say in the twit-sphere, @-me. d signature.asc Description: PGP signature
Bug#968465: ITP: beaudiomer -- generate input for autocut from annotated beamer presentation
Package: wnpp Severity: wishlist Owner: David Bremner X-Debbugs-Cc: debian-devel@lists.debian.org -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 * Package name: beaudiomer Version : git snapshot Upstream Author : Jim Fowler * URL : https://github.com/kisonecat/beaudiomer * License : to be clarified Programming Lang: Python, LaTeX Description : generate input for autocut from annotated beamer presentation Beaudiomer is a LaTeX package and python script which takes a beamer presentation with additional \audio and \video and \wait commands and produces an .xml file suitable for autocut. -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEEkiyHYXwaY0SiY6fqA0U5G1WqFSEFAl84jj8ACgkQA0U5G1Wq FSErkhAAuqRbMgk+rF3uPwXrwmokqwF1cENoIdDS8+hY4aAK0axecosNdsknyLOY bXhwV5I5s5nGV3sdqPcct+TzDO8NOTUUGMC1bma50RCxktlHzLJasp14/I57FakR ARNGY9/RtFvbb/fI62Y/SicaplfbrjXfBucGu/QLoW8FORLXc5pMR2MhzA5NJC3W KH72LZdBTYVEcERkmN0eZYfaHD5t/sUjHYewML22MjMeXqnmVKnjsUE2yDdlR3UT 8l0RgtG1kcNVZk2DpOEOpshsKD0Y18zi2tFHDFLbtRA9YBW+gpNojvmmJYSvPbT0 GC2FAsrrhFytD1/FA1BRBC+jhzY2WZ8s987cv+ZGUkm4vzOIzb0NOjI/SJajf3lw VgLHtje0bKwGVF+dBA0NUCaCZgRsaylkq2XEVZZ0Ejdonwgnop2jNff2fM8kRdJ/ nLevBNFqWyVkqhgY1JpVT5n3SwkB2ZaFjAlyVKK24VOLU2rkZ+S9P3bk0MGWQtSf DyqjIT4GofeD3rmYnZmpBG/eJZx5dr9/d0j0TMxrl63lXDK28+gZlTPAsSiGrr9C c+okh2tSgrTOY6f58jovtlVkDvp05+CuDZiYH3rxNry2yNLs+QkMSiGjahVcI5Xy E8jj806X+ABMfhR2wxj8e7ZWn1aB8OJifQGAGaoH31kj0m3+I74= =uzd2 -END PGP SIGNATURE-
Bug#968464: ITP: autocut -- cut off silent parts of videos and concatenate them
Package: wnpp Severity: wishlist Owner: David Bremner X-Debbugs-Cc: debian-devel@lists.debian.org -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 * Package name: autocut Version : 2.0.0 Upstream Author : Jim Fowler * URL : https://github.com/kisonecat/autocut * License : GPL3 Programming Lang: python Description : cut off silent parts of videos and concatenate them This tool takes a list of video files, listens to the audio to determine where the speaker starts and stop speaking, and builds an edit list suitable for melt. The package requires python3-librosa, not yet in Debian, and melt (already present as a package of the same name). -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEEkiyHYXwaY0SiY6fqA0U5G1WqFSEFAl84jNgACgkQA0U5G1Wq FSFw5g//RbmsSpjBgmQdOO+a81Wngg4i45pJOYrh/RcfO/G5Xg5OF/1osHymsSA5 NKIU/RuLUEj6DooBWTwn57m0JQjmSI1qWty/q/W18yOCeFENCIyj1bSXIxsLlbxY hfY2npc7EdoRkW/Y4bmfz9mGob78KzkRvbdx/fPU9lz0f5Ej7AoOsVEzKLxWoUig klnWvBWRIXoojjOqTAT9W2ufAoV+Wp6EyTu2c43ygw8Fl2f0cd+6A0GNgUDYvL0p JeWVtqquD+0jc5tHKEhDTLbBuDl8KJMXPa4YSb/m/YGsrn4RJJp/3elaT672xI8Z hRmPJZIdUR1qm5YfcAaCjxsRpP7eJGpMY/6oQ6gqxTOZ/TCUIskGGQrqS4EPjCdx ifOVtjz03ewJRNuZVD2UvKz1+U3U1SH5yR8ba7pVfayQrXdlfpeCTFqgHHoLoFaQ fVVSsVphDrRKq87o4EyIQtXGAkWepVQb21C2TLoOzQMvcc6ZrvKFGV6CJ0VgiS6o mRpNEMTZhVcBa5FEt+SW5jlSuXMGpfT/McRwn9cBdWUVMei/Zrr5d6LbgdNhWuaF 15X/CDMYMYDG2y7hqDkFgDD2Uzhh9gZuPadBjml+MubvzQoq5su6k9Qcd9PXYfGh uWNxRbq/ZgU6RQ1Pd7iRUDrwC1xg35cQ7CSXaIvXMUgZD96qg+U= =MJke -END PGP SIGNATURE-
Bug#958176: ITP: elpa-pos-tip -- emacs library to provide enhanced tooltips
Package: wnpp Severity: wishlist Owner: David Bremner -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 * Package name: elpa-pos-tip Version : git snapshot? Upstream Author : Piotr Kalinowski (maintainer) * URL : https://github.com/pitkali/pos-tip * License : GPL2+ Programming Lang: emacs-lisp Description : emacs library to provide enhanced tooltips This is a new dependency of elpa-racket-mode, and will be maintained in the debian emacsen-team Description from upstream, probably needs modification ;; The standard library tooltip.el provides the function for displaying ;; a tooltip at mouse position which allows users to easily show it. ;; However, locating tooltip at arbitrary buffer position in window ;; is not easy. This program provides such function to be used by other ;; frontend programs. -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEEkiyHYXwaY0SiY6fqA0U5G1WqFSEFAl6cOugACgkQA0U5G1Wq FSFZdxAAqpydxMvbXZwzYGoD/4y82OCHYUhOT2GqXT/rlOj5KEQJKRhUq2CPOVGs 4oHF/0Gn3IEFH1UKBwjZrtAvmztpNGegZ7QJ0/x4OkjeuX2ZpSA/tZe66SjSztE4 v+ejpZxLyxbOaaRcqSpAR8gQqCiu0QiQZpT5pwDkfXyjkXYmdw0zZBXxRAFvFDmM Aj9W7vWrq4auJvxF8wnPh3eaVfwOi8TBmuWetZG6ATWroP0NI7wAqplzdtXFMAds 2oEd89zHwa95aCiitzOraDawOM1mvrBHC4stIQvAH17jFhx63DDc+r2zbaqtAwjz XiIxKT9tHfr4MwZxRDAxk/u/oSdEQUBv4l8+nmDdrDNTOdAHXr6u7UdvcwJPgxJ9 y4pyF6AK9hLC7kJHaTUOm3mfvaC0fYu0Cfu6aNTAaK2bGPTXghCy8bM9/k2iDQM0 4aaCuhj9wxUXXxatBq0RrjP14WT04zDzfxPEqGsus2ii+T3imLQQrVf5+UuVHVRi 9P1kcgrvhxnrkwEk7Gc0Ona1Lgwht/jYyvA3UYygRcCA2oVUrFE5aUTtwkPLb9TS /95tb+74pjSWNU0iQ3MPEERRlhb6Dck64/PHJAz42mj3p3WXOQ4H9w82NEgQXQij 9fLw435NSDzMGHPt2JAL6+qfoiGx9+wt2in577Mv7ivF7MQ8dZk= =PJ64 -END PGP SIGNATURE-
Re: apt 2.0 release notes
Julian Andres Klode writes: > > apt install _toremove +toinstall > A common convention is to do something like apt install -- -toremove +toinstall I would prefer that to rolling our own syntax, unless there's some good reason (other than the small amount of extra typing) d
Re: Best practices for Debian developers who are also upstreams?
Otto Kekäläinen writes: > Hi! > > Thanks for the example. I see you even maintain the changelog in upstream: > https://git.notmuchmail.org/git?p=notmuch;a=blob;f=debian/changelog;h=4f7457cd7f588e6d3a821bf1530cc1f8742c8d6f;hb=refs/heads/master Yes. > > But apparently "upstream" releases are decoupled from also bumping the > Debian version? > > https://git.notmuchmail.org/git?p=notmuch;a=commit;h=3efa2ad72c8ffd8183fab2cd6592f35e72fbb7d7 > > This means debian/changelog shows "wrong" version at least for one commit > and that would not work in the CI pipelines I use as build products would > end up with inaccurate version strings. This is something I seek to find an > elegant solution for.. We're obviously less focussed on CI than you are. The fact that it takes a couple commits to make a release has never been problematic for us. I guess if it was important, you could do all the version updates in one commit. d
Re: Best practices for Debian developers who are also upstreams?
Otto Kekäläinen writes: > Hello! > > I've ended up in being both the maintainer in Debian and an upstream > developer for a couple of packages and I have been fantasizing about > how to optimize my workflow so that I primarily fix all bugs and do QA > directly on the upstream development version (=upstream git master) > and then have only a very small overhead work then importing and > uploading new upstream releases in Debian. > > Is somebody else already doing something similar like this? > Any tips, blogs, examples on the topic? I basically maintain notmuch that way. [snip] > My goals would be: > - have debian/ in upstream repository, and a CI that does the bulk of > Debian QA on every upstream commit and immediately gives feedback to > upstream devs that "break" something from Debian QA point of view I do have debian in the upstream repo. salsa CI is currently not working due to an obscure bug involving emacs and docker. I do provide an upstream build target to make snapshot packages to help people test. And we use travis, but only to test the upstream builds. > - have the delta of Debian debian/ an upstream debian/ as small as possible This is generally zero. I guess it comes down to definition. There is no seperate Debian debian/ dir as far as I'm concerned. > - fix all bugs detected in Debian directly at upstream when possible Sure. I typically make point/micro releases for non-debian specific problems. Although the package is non-native for flexibility, I mostly treat it as native. > - when not possible, fix them "locally" first in Debian and eventually > have it upstreamed I'm not sure I follow you precisely, but in my case I make a branch in the upstream repo for e.g. stable updates. > - bonus: import upstream releases as git operations without having to > export and import tar.gz packages I have only one git repo, so there's no importing per se.
Re: Git Packaging Round 2: When to Salsa
Sam Hartman writes: >> "Ansgar" == Ansgar writes: > > Ansgar> On Thu, 2019-09-12 at 08:14 -0400, Sam Hartman wrote: > Ian> 1. The maintainer's git repository branch format must be > Ian> documented. Otherwise another contributor has to guess. This > Ian> could be done either by doing maintainer uploads with dgit > Ian> (since recent versions of dgit include the maintainer branch > Ian> format information in the git tags), or perhaps by writing > Ian> something in README.source. > >> > >> Makes sense. My take is discussion on debian-devel strongly > >> supports making it easier to figure out what branch format people > >> are using. > > Ansgar> I don't see much value in this requirement (besides > Ansgar> additional work). One should look at the repository anyway > Ansgar> whan planning to do changes (to match the existing style > Ansgar> used); one would naturally see how files are organized. > > I actually find it annoying to figure out which branch format something > is. > I do the work you suggest, but automation or documentation would help me > as a developer. I just went through a batch of 240+ team uploads (because *sigh* no arch-all bin:NMUs). I can confirm it's annoying to have to figure the the git workflows involved when working at even this modest scale. If we're not going to enable people to work on multiple packages, then I (still) don't really see the point of the Debian salsa team. d
Re: Git Packaging Round 2: When to Salsa
Sam Hartman writes: > > I did do a bit of looking at data. > In my unstable sources.list, there are 17863 source packages that > include salsa.debian.org in the vcs-git. Of those, 2192 are in the > debian group. > That's the largestsingle group; perl-team (next) comes in at 1417. > > The debian group is larger than all the individual accounts used on > salsa combined according to vcs-git in unstable. Sure, but there's a lot of inertia from collab-maint on alioth when it was the promoted / only-sensible option. I'd guess that most collab-maint packages were ported to the debian group. d
Re: Git Packaging Round 2: When to Salsa
Ian Jackson writes:
> Sam Hartman writes ("Git Packaging Round 2: When to Salsa"):
>> Discussion Comments
>> ---
> ...
>> I realize that not everyone wants all developers to have push access to
>> their packages. If you have a firm idea about that, then this
>> recommendation is not for you. I also realize that by starting by
>> recommending the debian group I'm recommending a more permissive
>> maintainership model closer to low threshhold NMU than only NMU my
>> packages after explicit confirmation. I think that the dh discussion
>> supports the conclusion that we are OK with that as a project *as a
>> recommendation*. If a maintainer doesn't like that level of openness,
>> that's fine. My take though is that when recommending what to do to
>> people who do not have preconceived ideas, more open policies like the
>> debian group and low threshhold NMUs are in alignment with the project.
>
> I absolutely have no problem with recommending this as a practice to
> the individual maintainer who doesn't know better. However, for this
> practice to be useful:
>
> 1. The maintainer's git repository branch format must be documented.
> Otherwise another contributor has to guess. This could be done either
> by doing maintainer uploads with dgit (since recent versions of dgit
> include the maintainer branch format information in the git tags), or
> perhaps by writing something in README.source.
>
> 2. We need to have a shared understanding of when people may push to
> branches in the debian/ repository. I think you are proposing that
> the answer be "if you do an NMU". I would support this but it is a
> change to current practice. We also need to understand how this
> relates to the recommendation to NMU to DELAYED.
>
> 3. The answers to (1) and (2) need to be documented.
>
> I would like to suggest another possible widening of when to push to a
> branch in the debian group on salsa: "if you would do an NMU, but for
> some reason an actual upload is not desirable right now". Examples
> could include packages owned by QA, if a maintainer invites you to
> make a change, if a bug needs fixing but for transition or migration
> or similar release management reasons it is not a good time for an
> upload.
>
This first part is consistent with my intuition / understanding. I
haven't had time to absorb the rest.
d
Re: Git Packaging Round 2: When to Salsa
Russ Allbery writes: > 3. Anyone who comes from a tech company / Silicon Valley development >environment is probably going to already be used to this style of >collective ownership (along with politeness conventions about not >messing with other people's stuff unless you have talked to them or >know what you're doing), since this is an extremely common development >model there, and this will feel natural. This specifically I have to disagree with. I think anyone with this background will be used to doing merge requests. I think the idea of needing direct push access to many repos is specific to Debian. Maybe there are different subcultures out there, and we have exposure to somewhat disjoint sets. > 5. We can easily make mass changes to these packages, which is something >we've not done much of historically but which would be a powerful new >tool. It would be even more powerful if we could do that for all >packages, of course, but that has more social tradeoffs, and it's still >useful to be able to do mass changes to a class of packages that may be >the ones with the least "attached" maintainers to the project who may >not be following project-wide discussions. In order mass changes to be possible, there needs to be a common workflow for packages in the debian group. In order for automation to work, we need not just a general recommendation but a rigid policy. I'm not objecting to that, but I don't think it exists now. In fact I think this is probably an interesting answer to Zigo's proposal to make a uniform git workflow mandatory, which is to do that for the Debian salsa team. I'm also not sure if this is a completely rational reaction, but I'm not currently very comfortable with any DD being able to make global changes to thousands of git repos. I think we haven't yet developed any kind of social conventions or rules about when that is appropriate, and we don't have much project experience with it. That's possibly a seperate discussion, but if mass changes are the justification for some other policy/norm/standard/reccomendation, then maybe it should be discussed first.
Re: Git Packaging Round 2: When to Salsa
Sam Hartman writes: >> "Jonas" == Jonas Smedegaard writes: > > > Jonas> I think there is a general consensus on working in teams, and > Jonas> therefore using git repos belonging to teams - but not to use > Jonas> that one giant "team" called "debian". > > What would you recommend people do if they have a package that doesn't > fit into an existing team. > > --Sam One option is putting them in their own user namespace. This is generally my preferred option for packages that are not maintained as part of a team. I think the option of merge requests reduces the need to give out direct push access. d
Re: Survey: git packaging practices / repository format
Ian Jackson writes:
> Ian Jackson writes ("Re: Survey: git packaging practices / repository
> format"):
>> David Bremner writes ("Re: Survey: git packaging practices / repository
>> format"):
> ...
>> > With unmodified upstream files in the main branch, plus debian/*, but
>> > usually no d/patches, I use git-debcherry to generate a quilt series at
>> > dsc build time.
>>
>> I think I understand this one a bit better than the one above.[1]
>> What constraints are there on the main branch, for this to work ?
>
> Also, how do you move to a new upstream version ?
use git merge, typically from an upstream tag, or from a debian specific
upstream branch with tarballs imported on top of upstream history.
Re: Survey: git packaging practices / repository format
Ian Jackson writes:
> Hi. Thanks for your contributions which I am trying to capture, but I
> don't think I fully understand them.
>
> David Bremner writes ("Re: Survey: git packaging practices / repository
> format"):
>> With modified upstream files in the main branch, plus debian/*, but
>> usually no d/patches I use a seperate (manually
>> rebased) branch for patches, and export those at dsc creation time using
>> a gitpkg hook
>
> Is this the same setup as described by Simon McVittie for xorg
> packages (eg, mesa) ?
I don't think so. My own usage is "purer" and doesn't involve quilt;
the mention of d/patches is probably a red herring here; I only
mentioned because I remember that some users of git-debcherry like(d) to
commit exported patches to be compatible(ish) with gbp.
> If not I don't understand, because you say both that the upstream
> files are modified in your main branch, and that there are patches in
> d/patches but that is in a separate branch.
> Are the same changes
> represented twice, then, on two git branches ?
The patch branch (which is just a regular git branch), is just a linear
sequence of commits on upstream.
> You say "a gitpkg hook". Is the hook script in Debian or is it ad
> hoc ? My table would perhaps want to name it.
yes, it is /usr/share/gitpkg/hooks/quilt-patches-deb-export-hook (in
the package gitpkg).
>
>> With unmodified upstream files in the main branch, plus debian/*, but
>> usually no d/patches, I use git-debcherry to generate a quilt series at
>> dsc build time.
>
> I think I understand this one a bit better than the one above.[1]
> What constraints are there on the main branch, for this to work ?
>
There are no (known) constraints on the main branch, but the degree to
which it "works" varies. It guarantees the same working tree as you
started with, but not a one-to-one mapping between git commits and quilt
patches. In particular there can be a "debcherry-fixup-patch" containing
some changes that could not be nicely linearized into patches.
> [1] git-debcherry solves a very similar problem to dgit's quilt
> linearisation, which is used for example by dgit to construct `3.0
> (quilt)' patches out of the commits made by an NMUer.
Yes, that's why I pointed git-debcherry out to you when you started
designing dgit :P
> And I think git-debrebase branches are always suitable for use with
> git-debcherry, but git-debrebase knows how to make patches itself so
> you don't need git-debcherry then.)
Sure, except if you have a project already using git-debcherry, where I
guess git-debrebase might not work.
git-debcherry itself does not modify history, only generates source
packages. There is a companion script 'git-refresh' that I think
was never packaged (attached for reference). The idea is to bring
patches to the tip of history again, which I guess is a simplified
version of what git-debrebase does.
git-refresh
Description: Binary data
Re: Survey: git packaging practices / repository format
Ian Jackson writes: > > Main packaging Delta from upstream Tools for manipulating > git branch represented as delta from upstream, > contains building .dsc, etc. > > Unmodified debian/patches gbp, gbp pq > upstream files,(only)quilt / dquilt > plus debian/* Manual patch editing > incl. d/patches > > Modified Direct changes git merge > upstream files,to upstream files (.dsc: 1.0-with-diff or > plus debian/*. single-debian-patch) > Maybe d/patches, depending. > History has direct merges from upstream. With modified upstream files in the main branch, plus debian/*, but usually no d/patches I use a seperate (manually rebased) branch for patches, and export those at dsc creation time using a gitpkg hook With unmodified upstream files in the main branch, plus debian/*, but usually no d/patches, I use git-debcherry to generate a quilt series at dsc build time.
Re: Please drop anacron from task-desktop
Holger Wansing writes: > > Any thoughts on this? > > Is there still a broad necessity for anacron? > Are there still many packages, that don't rely on systemd timer units? > Presumably packages that work without systemd, but still need to periodic activity? d
Re: Our build system may be broken: /bin vs /usr/bin
Michael Biebl writes: > > Most packages which are affected by this issue I've seen so far search > for the binaries in $PATH and encode the full path of the first find. > Since PATH is typically set to something like > > PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games > > the first find will be /usr/bin/sed on a merged-/usr system. > I suspect if you had a locally installed sed in /usr/local/bin, your > package would encode that as full path, i.e. would be misbuilt. > In the end it's a bug in your package which should be fixed there. > > As Marco said, the obvious and simplest approach is to nail down the > paths during build to a path that is known to work everywhere, i.e. in > your case /bin/sed. > A more elaborate fix would be, to not use any hard-coded paths. For scripts this conflicts with the requirement/suggestion to hardcode the shebang line. I don't know a good general solution, it seems to require ad hoc extra configuration to fix interpreter paths at build time (i.e. upstream build system cannot really expect to find interpreter paths if we move them between build and execution). d
Re: salsa.debian.org: merge requests and such
Mattia Rizzolo writes: > At least now DDPO shows such things in the VCS column. I think the "!1" > is way too small and very easy to miss, but that can be improved if > anybody has a shed of ability with UIx/CSS… (which I don't) I'm not especially proud of it, but I mostly won't see things that don't arrive in my mailbox. Polling web pages just isn't going to happen for me. I understand other people have different ways of working, but I suspect I'm not alone on relying on problems being reported (typically by the BTS). d
Re: Limiting the power of packages
Laurent Bigonville writes: > Lars Wirzenius wrote: > >> * default: install files in /usr only >> * kernel: install files in /boot, trigger initramfs >> * core: can install files anywhere, trigger anything >> * maintained-by-liw: full power to do anything >> >> This might be implemented in various ways. For example, dpkg could >> create a temporary directory, and bind mount the directories the >> profile indicates are needed, into a temporary shadow of the full >> system. Maintainer scripts would be run in the shadow environment. >> Thus, if they try to do something that isn't allowed by the packages >> profile, they can't. > This can be done with SELinux as well, the maintainer scripts can be > labeled and dpkg will run them in the desired context. I like the general project, but feel obliged to point out that having maintainer scripts fail is not nice for users, so we'd need to think about how to handle security/liw-classification failures. d
Re: Updating the policy for conflicting binaries names ? [was: Re: Re: New package netgen-lvs with binary /usr/bin/netgen - already taken]
Andrey Rahmatullin writes: > Last upload of ax25-node was in 2008, in 2009 it was effectively orphaned, > the TC bug was filed in 2011 and resolved in 2012, in 2015 ax25-node was > removed with "ROM; no activity, open security issues, de facto orphaned" > (the status that was true when the TC bug was filed). In 2017 the previous > TC decision was repealed. To be clear, the TC knew that ax25-node was removed when they (we) repealed the previous decision. signature.asc Description: PGP signature
Re: Let's start salvaging packages! -- disucssion phase closing soon.
gregor herrmann writes:
> On Mon, 03 Sep 2018 22:22:25 -0300, David Bremner wrote:
>
>> You will have to use your judgement as to whether a given
>> combination factors constitutes neglect;
>
> "combination of factors"?
correct
>
>> in case the maintainer disagrees they have only to say so (see below).
>
> "they only have to say so"? The former sounds more like
> en_${germanspeakingcountry} to me (says the en_AT speaker to the
> native one ...)
It sounds quite normal / idiomatic to me.
d
Re: Let's start salvaging packages! -- disucssion phase closing soon.
Tobias Frost writes: > On Mon, Sep 03, 2018 at 08:17:24AM -0300, David Bremner wrote: >> OK, I understand the reasoning, but I hope we can improve the wording on >> both sides a bit so it's clear that the rule is "use your judgement, and >> if you're not sure about your judgement, refer to these numbers in the >> wiki, which represent a current concensus". Assuming my summary is >> correct, of course. > > Yes, your summary is correct. I'm happy to make the wording a bit more > clearer and start by shamelessly stealing your sentence as a base for it > ;-) Here's my attempt at rewording your rewording: You will have to use your judgement as to whether a given combination factors constitutes neglect; in case the maintainer disagrees they have only to say so (see below). If you're not sure about your judgement or simply want to be on the safe side, there is a more precise (and conservative) set of conditions in the wiki. These conditions represent a current Debian concensus on salvaging criteria. In any case you should explain your reasons for thinking the package is neglected when you file an Intent to Salvage bug later. I thought the changed wiki wording was ok (and easier to change anyway).
Re: Let's start salvaging packages! -- disucssion phase closing soon.
Tobias Frost writes: > > The split was actually thought to be a feature [1] :) > It was to make the process itself less normative about the actual > (concrete) figures/criterias, but still give safe figures to e.g > necomers they can rely on, and on the other side enable more advanced > people to reasonably deviate from it > (but with a strong documentation/justification requirement). > OK, I understand the reasoning, but I hope we can improve the wording on both sides a bit so it's clear that the rule is "use your judgement, and if you're not sure about your judgement, refer to these numbers in the wiki, which represent a current concensus". Assuming my summary is correct, of course. d signature.asc Description: PGP signature
Re: Let's start salvaging packages! -- disucssion phase closing soon.
Tobias Frost writes: > Hallo everyone, > > This is a gentle reminder regarding the Salvaging Process discussion! > > For all of those, who did not yet have read the proposal, but still want > to participate in the discussion, please step forward now, as I plan to > start to work on finalizing the text after Saturday, September 1st. Hi Tobi; I'm not sure it's a good idea to have the definitive criteria for salvaging in the wiki. I guess partly I'm not too comfortable with the lack of definition of an process to change those criteria in the wiki. It's also strange to me to have the salvaging description split across two locations. I'd suggest that whatever the "real" conditions are (even if the concensus is to use a less formal set of conditions like those given here), that they go in the same document as the procedure they enable. d
Bug#907331: ITP: webmacs -- keyboard focused web browser with Emacs look and feel
Package: wnpp Severity: wishlist Owner: David Bremner * Package name: webmacs Version : 0.6 Upstream Author : Julien Pagès * URL : https://github.com/parkouss/webmacs * License : GPL3+, MPL2.0 (no exhibit B), MIT Programming Lang: Python, C, C++ Description : keyboard focused web browser with Emacs look and feel Long description to be written. Co-maintainers welcome.
Re: Let's start salvaging packages!
gregor herrmann writes: > On Sun, 29 Jul 2018 17:40:49 +0800, Tobias Frost wrote: > >> A package is eligible for salvaging if it is in clear need of some love >> and care, i.e. there are open bugs, missing upstream releases, or there >> is work needed from a quality-assurance perspective; AND there is the >> need to upload the package to deal with these issues; AND at least one >> of these criteria applies: [...] > > I think that's maybe a bit too complicated. > It all makese sense somehow in itself (and I guess I was involved in > coming up with these conditions some years ago) but reading it I have > the impression that I'll never remember it and will have to very > carefully and concentrated re-read it in every case where I might > want to salvage a package and hope that I get the result of several > ANDs and ORs right. I sympathize with wanting simpler conditions (they did get simpler during debcamp), and it might be that these can further simplified without harming anything. On the other hand, at least for me, one of the main motivations is to make this process accessible to new contributors to Debian. In this context I think it is much better to explicit, both to shield would be salvagers from negative reactions and to shield package maintainers from "unreasonable" [1] salvaging attempts. [1]: the scare quotes acknowledge that the current discussion is rooted in the idea of package ownership, and doesn't seek to radically change that notion.
Re: Let's start salvaging packages!
Guillem Jover writes: > >> [c] Level of activity should be defined in favor of the maintainer if in >> doubt. A maintainer may ask for help or welcome a NMU. This counts as >> activity with respect to salvage criteria. If a package lacks uploads, >> there is no visible bug triaging, and - if applicable - the source >> package's VCS does not show commits this is an indication, that the >> package is not well maintained. > > Some packages might not show activity for longish periods of time, > because maintainers batch changes, for example to do at least one > upload per release, with general packaging and QA updates/improvements, > etc. > > Also there might be bugs open that are difficutl to fix (with no > patch), etc, that might show no activity for a long time. > > So I'd probably qualify the requirement above. I'm not entirely sure > how though. I mean [c] kind of covers it superficially, but I'm not > sure that's clear enough or if the intention was something along these > lines. For example, if there's a difficult bug open, and then a patch > is sent and gets no reply, that could count as inactivity in my book, > but not otherwise. At least for me it was clear that replying to bugs counts as activity, but maybe that was more my preconceptions than the wording of [c]. I would be fine with replacing/augmenting the wording about bug triaging to cover all BTS activity related to the package in question. On the other hand the wording "if in doubt" covers the case you mention.
Re: Let's start salvaging packages!
Guillem Jover writes: > Some packages might not show activity for longish periods of time, > because maintainers batch changes, for example to do at least one > upload per release, with general packaging and QA updates/improvements, > etc. > > Also there might be bugs open that are difficutl to fix (with no > patch), etc, that might show no activity for a long time. > > So I'd probably qualify the requirement above. I'm not entirely sure > how though. I mean [c] kind of covers it superficially, but I'm not > sure that's clear enough or if the intention was something along these > lines. For example, if there's a difficult bug open, and then a patch > is sent and gets no reply, that could count as inactivity in my book, > but not otherwise. Would it be a big hassle for you to reply to a hypothetical salvaging bug saying essentially what you just wrote, or maybe some short form? As far as I understand that would be enough to stop any salvaging process. I agree that it's a bit of busywork for the maintainer, but maybe that bug could be left open and marked wontfix to avoid too much opening and closing of bugs. David
Bug#864621: ITP: racket-mode -- emacs support for editing and running racket code
Package: wnpp Severity: wishlist Owner: David Bremner -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 * Package name: racket-mode Version : 20161103+0+gab6255718 Upstream Author : Greg Hendershott * URL : https://github.com/greghendershott/racket-mode * License : GPL2+ Programming Lang: racket, emacs-lisp Description : emacs support for editing and running racket code Provides a major mode to edit Racket source files, as well as a major mode for a Racket REPL. The edit/run experience is similar to DrRacket. This will be maintained as part of the pkg-emacsen-addons team. -BEGIN PGP SIGNATURE- iQGzBAEBCAAdFiEE3VS2dnyDRXKVCQCp8gKXHaSnniwFAlk9lu0ACgkQ8gKXHaSn nizx/Av/TQ1/LMouhVfA6VJdfwMgQo6E8+7xBMg7gQ1f/v5Pwoc2FZTj7aTGFl6b wBMotced4/G7ikcpOw3xw1o7ObqvElvGetFctueIJoQw3yhvY2RsqrH5Uk25SeKx iU96/rBuuRzM4h4GGFO14cWFZOkvoHMENhUcwcyjmUWdQNVIVZnC8cwlKDIy3aV5 kFKZPxg2G/xYuxsY4GP1lX65ZwcXJXClvU+r8junUdIynaXpzyo2ZBT7RY7BO0Kj Aym6ZB1vABCh96dYmOSi1IvhBRKTDJJXRXLZofQtDNrVNE9HPCMo1eqLdAqWqLHn zTaflR1omT4LNDMmJlB4AgMeB81haNB/Uwj8MUft71SYOo4qivhXVU2jbKeHqahP fEScWo3lw2pP98UA/pLpojtzL6nbxRgemcSw2edKhkBj2bkI277Oo7o1RenBtrBz exbU8017Oa9p2m20fabWMWeJkJjOYC4RqKMqsYpSeQpD1ZNuEYQS1DVfl5g3poEK 7+SjNnif =/0ar -END PGP SIGNATURE-
Bug#837660: ITP: pass-git-helper -- Git credential helper interfacing with pass
Package: wnpp Severity: wishlist Owner: David Bremner -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 * Package name: pass-git-helper Version : 0.3 Upstream Author : Johannes Wienke * URL : https://github.com/languitar/pass-git-helper * License : LGPL3+ Programming Lang: Python Description : Git credential helper interfacing with pass Maps hostnames to pass(1) keys to retrieve passwords and optional usernames. Some initial packaging can be found at https://anonscm.debian.org/git/users/bremner/pass-git-helper.git -BEGIN PGP SIGNATURE- iQGcBAEBCAAGBQJX1+UNAAoJEPIClx2kp54sY6wL/2LJ87wLEeqUSxM/4UsHJprN fOVn1r+ELLz+WkMMLCDlGNvD2t+WnON8HM0/fpS6+4/FORbR/U2TkOOAhnQdTWhu kSHEzUAdaHQ5yQNLzaIlmPx76eYD3hRE6xk110BS7iYfv2EUB4Jerm/5rTAlHm1D pc3dSlCYRiPvw9/3FqITMEV3e/A+jLxt/1oOYN+SXYb0CLtIU/GMZKob1zjjutvE SlRDBI1mC47v1H+cUxoNYMPs3YC+bezmK+B5frqMBarxW3cSANrnz2beeiRsbPW2 9yRQWegiFwHTWrXutgKv7qzA7HITp6KA119xgS7Lf0AhPEsmitWE+qIJjhHJB1ER 9WsnAfUBgl1XgyIc6W8iPrxQ2aYpxCidSUjGlZ4JwFU/yROD0kpue1axwxFYirxG 2rhbDkjl/B4E3LBCi5vPbE/Xc1HkeRq7JnNdpsoRbxV0IIk4ZU+C1lO2ftaLfRKh NNbrcJD+hxdlChBFi9+3Q22fzLp/EysVsJclmCjr1Q== =hDuz -END PGP SIGNATURE-
Re: IMPORTEND squid3 stable needs update
startrekfan writes: > *squid3 Version 3.4.8* is deployed in the Jessie stable repository.* This > version is outdated and has some security risks!!*. Version 3.5 is more > secure but unfortunately it's only marked as unstable If there are security bugs in squid3 (or in any other debian package), please write with specifics to secur...@debian.org or t...@security.debian.org For more details, see https://www.debian.org/security/faq#contact signature.asc Description: PGP signature
Bug#798209: ITP: markdown-mode -- mode for editing Markdown-formatted text files in GNU Emacs.
Package: wnpp Severity: wishlist Owner: David Bremner Package name: markdown-mode Version : 2.0snapshot78 Upstream Author : Jason R. Blevins URL : http://jblevins.org/git/markdown-mode.git License : GPL-2+ Programming Lang: emacs-lisp Description : mode for editing Markdown-formatted text files in GNU Emacs. The mode provides syntax highlighted, and keyboard shortcuts for editing, compiling and previewing markdown. This package will be maintained by the nascent Emacs Addons packaging team. There is currently an old version of this package in emacs-goodies-el, but I think it's substantial enough to stand on it's own as a package. If/when this package is uploaded, I'll file a bug suggesting it be removed from the bundle. There are also substantial maintainer and user advantages to having a standalone package. Because of the way this is packaged (using dh-elpa), there will not be file conflicts with the bundled version. preliminary packaging is available via git clone git://anonscm.debian.org/git/pkg-emacsen/pkg/markdown-mode.git
Bug#792836: ITP: circe -- Client for IRC in Emacs
Package: wnpp Severity: wishlist Owner: David Bremner * Package name: circe Version : 1.6 Upstream Author : Jorgen Schaefer * URL : https://github.com/jorgenschaefer/circe * License : mostly GPL3+, some BSD bits Programming Lang: Emacs lisp Description : Client for IRC in Emacs Circe is a Client for IRC in Emacs. It integrates well with the rest of the editor, using standard Emacs key bindings and indicating activity in channels in the status bar so it stays out of your way unless you want to use it. Complexity-wise, it is somewhere between rcirc (very minimal) and ERC (very complex). -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150719081021.19460.49279.report...@maritornes.cs.unb.ca
proposal to (maybe) use "elpa-" package prefix for emacs lisp packages
I've just uploaded to experimental/NEW a packaging helper called dh_elpa (for the punny among you, pronounced D-helpa) that installs upstream emacs lisp "packages" for GNU emacs in a way that is compatible with the native "elpa" packaging system [1]. Currently this has the limitation that it doesn't deal with byte compilation at all, but for lots of simple packages it works fine without it, and it means the resulting packages can be maintainer-script free. This might turn out to be a terrible idea and never leave experimental, but I'm thinking of using the prefix "elpa-" for packages of this type. For example I currently have a source package called "circe" [3] that creates two binary packages elpa-circe and These are (cue flames) only compatible with GNU Emacs, and only with emacs >= 24. On the other hand, many interesting and useful packages fall into this category. I haven't decided so far how this will relate to the current emacsen-common infrastructure, if at all. If your interested in playing with the tool, it's available in a public git repo [2]. I'd suggest emacs related technical discussion to debian-emacsen@l.d.o and discussion about package namespaces in debian-devel. Please CC me with any answers. I'm not on debian-devel, and I don't mind 2 copies for the other list. David [1]: http://www.gnu.org/software/emacs/manual/html_node/elisp/Packaging.html#Packaging [2]: git://pivot.cs.unb.ca/dh-elpa.git [3]: git://pivot.cs.unb.ca/circe.git signature.asc Description: PGP signature
Bug#779490: ITP: three.js -- lightweight
Package: wnpp Severity: wishlist Owner: David Bremner * Package name: three.js Version : 70 Upstream Author : Mr.doob * URL : http://threejs.org * License : MIT Programming Lang: JavaScript Description : lightweight 3D graphics library JavaScript library that provides a high level API to create 3D graphics in the browser using WebGL. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150301121800.12739.75976.report...@maritornes.cs.unb.ca
Re: Second call for Debian projects and mentors in GSoC 2013.
David Bremner writes: > For the full sales pitch, I refer you > > http://lists.debian.org/debian-devel-announce/2013/02/msg7.html > > It turns out we don't need our list of projects until May the 28th. > Err, sorry. That's March the 28th. d pgpU2nCiKuUOA.pgp Description: PGP signature
Bug#693859: ITP: pixz -- parallel, indexing version of xz
Package: wnpp Severity: wishlist Owner: David Bremner -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 * Package name: pixz Version : 0.0.0+git$something Upstream Author : Dave Vasilevsky * URL : https://github.com/vasi/pixz * License : BSD 2-clause Programming Lang: C Description : parallel, indexing version of xz This is another parallel xz compressor/decompressor. Better long description to follow. You can look at pxz to get the general idea. Or imagine multithreaded xz. So why another parallel xz in the archive. - - This one seems about 25% faster compressing in some simple tests I ran (compressing a 2.7G file with 6 threads, maximum compression). Decompression seems to be a wash between xz, pxz, and pixz on files produced by xz. On files produced by pixz, pixz is noticably faster - - More importantly it does not seem to suffer from (because of being "indexable") http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=686502 i.e. busybox xz also works on the output of pixz The lack of releases is a bit annoying; perhaps upstream can be convinced to make some tags. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iJwEAQECAAYFAlCsOlsACgkQTiiN/0Um85nQ/AP+P9p1aoYfBz5uedA56KOO4r1i ZWXGcvGnVWRWjpqlueo/MP6xLP7rNpcOU6nkef9QC5iTJVBseWsItdDGnZ5lXhDZ UzO1MW8dXlCEDTg6qXECKrarTjzKWvvOY8syr+reKY49BBdHc60I7nv4ElXvC4X8 6omfI8s4AifX55n0/gI= =ULCR -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20121121022011.24499.34110.reportbug@zancas.localnet
Calling Noah Slater
Hi All; A three weeks ago Jakub Wilk noticed a long standing file conflict between racket and planet-venus (#680685). I realize three weeks is not _that_ long to wait for a response, but we are in the freeze and I'd like to resolve the bug. Does anyone (or Noah?) know if Noah is still interested in his Debian packages? It seems like it is has been a few years since he last did an upload. David -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87obn0vzpm.fsf@zancas.localnet
Re: Calling Noah Slater
David Bremner writes: > A three weeks ago Jakub Wilk noticed a long standing file conflict > between racket and planet-venus (#680685). I realize three weeks is not > _that_ long to wait for a response, but we are in the freeze and I'd > like to resolve the bug. > > Does anyone (or Noah?) know if Noah is still interested in his Debian > packages? It seems like it is has been a few years since he last did an > upload. Gah, I typoed Noah's email in the first message of the thread, sorry about that. d -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87lii4vz8o.fsf@zancas.localnet
Re: gitpkg with a quilt export hook
Brian May writes: > On 24 May 2012 20:28, James McCoy wrote: > >> Also, see gitpkg.force-overwrite-orig in gitpkg(1). > > Setting that to False will result in gitpkg aborting instead of just > assuming an answer of No. In the next version of gitpkg, there may be a third setting of this variable to assume an answer of No. d -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87ehq9undu.fsf@zancas.localnet
Re: gitpkg with a quilt export hook
Brian May writes: > On 16 May 2012 19:45, Bastien ROUCARIES wrote: >> You could use gitpkg with a quilt export hook. i use it regularly with >> imagemagick and it work perfectly (it is gitpkg over git over svn). > > Out of curiosity, how do you use that and not have it include changes > to debian/* ? That appeared to me my problem trying to use this > method. Especially as some of my git commits change files both inside > and outside debian/* There is no magic in the included hook to detect or deal with such commits. Since the method requires you to keep your commits on a seperate branch which is rebased against upstream, I'd recommend splitting the commits when you rebase. d -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87wr41zxxt.fsf@zancas.localnet
Re: Making -devel discussions more viable
"Bernhard R. Link" writes: > My suggestion to everyone feeling the need to tell anyone on a public > mailing list that they should shut up because they are no contributors > is thus: Please refrain from any more posts to this discussion. I have nothing against this principle, and I do this. But I also stop reading such threads. And this means I read less and less of this list. d -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87bom8p3gz.fsf@zancas.localnet
Re: Teams in changelog trailers
On Sun, 19 Feb 2012 15:21:10 +0100, Jonas Smedegaard wrote: > On 12-02-19 at 08:44am, David Bremner wrote: > > We have both sponsoring and co-maintenance; there is no rule that says > > co-maintainers have have to be DD/DMs. > > Since only DD/DMs can upload co-maintained packages, same rule applies > there. > > Or did I miss your point? My point is/was that what you suggest sounds more like co-maintenance to me. So, people who dislike the current sponsoring system (i.e. leaving the sponsoree as the uploader in changelog) can co-maintain instead. Maybe we are proposing the same set of actions, and just giving it different names (your "improved sponsoring" is my "co-maintenance"). Obviously you are free to do what you like when you sponsor. A different, and more contentious point, is what the project should prefer. Given the state of near-collapse (by ratio of requests to active sponsors) of the sponsoring system, I would hesitate to impose too many requirements the process. As we both know, one person's innocuous requirement (e.g. let's all use dh7) is another persons reason to walk away from an activity. d -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87obsu262b.fsf@zancas.localnet
Re: Teams in changelog trailers
On Sun, 19 Feb 2012 13:15:19 +0100, Jonas Smedegaard wrote: > > Yes, In my opinion that goes for sponsoring too: The sponsor should add > herself/himself in the changelog to clearly advertise to the World whom > within the Debian web of trust proof-read and uploaded the packaging. > Hi Jonas; I understand the motivation, I think, of making sponsor responsibility more clear. But I think in general it is more important that the sponsor upload (or choose not to) a pristine package from the sponsoree. This avoids situations where the sponsoree somehow feels sabotaged by changes after they last saw the package, and it also matches my understanding of what the responsibility of sponsoring is: to act as a gatekeeper, but not to promise any further maintenance of the package (other than orphaning of the sponsoree goes MIA). We have both sponsoring and co-maintenance; there is no rule that says co-maintainers have have to be DD/DMs. One suggestion that came up on IRC was to have the PTS track the "who-uploads" information to make it more convenient for non-developers (or just lazy developers ;) ) to access, and more visible. David -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87mx8f0z7u.fsf@zancas.localnet
Bug#651660: ITP: jlog -- durable message queue library
Package: wnpp Severity: wishlist Owner: David Bremner * Package name: jlog Version : 0.0 (git snapshot) Upstream Author : Theo Schlossnagle * URL : http://labs.omniti.com/labs/jlog * License : BSD Programming Lang: C Description : durable message queue library >From the web site: libjlog is a pure C, very simple durable message queue with multiple subscribers and publishers (both thread and multi-process safe). The basic concept is that publishers can open a log and write messages to it while subscribers open the log and consume messages from it. The authors list is Wez Furlong Alec Peterson George Schlossnagle Theo Schlossnagle Alexey Toptygin The software can be downloaded from https://github.com/omniti-labs/jlog -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20111211010432.10573.63464.reportbug@zancas.localnet
Re: Status of circulars dependencies in unstable
On Sun, 04 Sep 2011 13:49:06 +0200, Josselin Mouette wrote: Non-text part: multipart/signed > Given the benefits for dependency resolvers to be able to guarantee the > dependency tree is actually a tree and not a DAG Pardon my terminology nit-pick, but do you mean "guarantee the dependency graph is actually a DAG"? The A in DAG is for acyclic. d -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87ehzwwerv.fsf@zancas.localnet
Re: Other OpenCL users anywhere?
On Tue, 30 Aug 2011 16:08:19 +0200, Bastien ROUCARIES wrote: > > Not sure documentation date from 5 days ago :) > > http://people.freedesktop.org/~steckdenis/clover/index.html > > See also blog about the clover google of code http://steckdenis.wordpress.com/ > > And git tree here http://cgit.freedesktop.org/~steckdenis/clover/ Ah, thanks for the better info than I found on the clover project. So it might be closer to being usable than my previous impression. I guess if this were packaged (and able to run at least some OpenCL programs) then it would alleviate most of my concerns about having the Opencl headers in main. David -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87sjoj9e0s@convex-new.cs.unb.ca
Re: Other OpenCL users anywhere?
On Tue, 30 Aug 2011 13:53:19 +0200, Steffen Möller wrote: > it seems like OpenCL is becoming routine. The -dev files are luckily > shared between many architectures from what I understood, just the > libraries/drivers are platform specific. The Khoros headers are indeed free, however as far as I know, there are currently no DFSG free OpenCL drivers (certainly none in Debian main). The SNU-SAMSUNG project [1] looks interesting, but only supports Cell/Arm/DSP now. There is also the Gallium3D effort, but as of 3 days ago [2] it looked like still a work in progress. So I guess I package consisting of only the headers would have to be in contrib at this time. And header packages in contrib are not that useful because they cannot be used by packages in main [3]. Perversely, including the Khoros headers in another source package seems ok with the letter of policy to me (since the drivers are not needed to build). I don't think that having a meta-package with only instantiations outside of main will fly either. But that is just a personal opinion. David [1] http://opencl.snu.ac.kr/ [2] http://cgit.freedesktop.org/mesa/clover/ [3] http://www.debian.org/doc/debian-policy/ch-archive.html#s-main pgp5VhTsDL5Vj.pgp Description: PGP signature
Re: Spending Debian money for porter boxes
On Mon, 22 Aug 2011 13:44:08 +0200, Tollef Fog Heen wrote: > The ones you mentioned on IRC were sparc and powerpc. PowerPC is > getting an extra debian.net porterbox as we speak, this one being a quad > 2.5GHz G5 with 6G memory and 500G disk. (It'll run a buildbot for > Varnish so it won't be a DSA machine.) Thanks to everyone involved with this. Lack of a G5 porterbox has been a thorn in my side for about a year now. Just this morning I noticed another powerpc build failure that I am pretty sure won't be reproducible on the G4 porter box. Thanks again, David -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/871uwdsjjl.fsf@zancas.localnet
Re: [kfreebsd] massive report for uninstallable FUSE packages
On Sat, 16 Jul 2011 16:10:18 +0200, Robert Millan wrote: > wikipediafs sshfs smbnetfs s3ql rofs python-fuse pytagsfs plptools > mythtvfs ntfsprogs libpam-mount libfuse-perl libconfig-model-perl > httpfs2 gphotofs gfarm2fs fusedav fts flickrfs curlftpfs bindfs avfs > aptfs I'm working on gphotofs, but shouldn't > > Depends: fuse-utils [linux-any] | fuse4bsd [kfreebsd-any] > this be something like Depends: fuse [linux-any] | fuse4bsd [kfreebsd-any] since fuse-utils is transitional. I'm also not sure whether it is better to use '|' or just ',' here. Probably it doesn't matter. d pgpxIpOmW2gWm.pgp Description: PGP signature
Bug#634065: ITP: permlib -- C++ template library for permutation computations
Package: wnpp Severity: wishlist Owner: David Bremner * Package name: permlib Version : 0.2.4 Upstream Author : Thomas Rehn * URL : http://www.mathematik.uni-rostock.de/lehrstuehle/geometrie/software/ * License : MIT-like Programming Lang: C++ Description : C++ template library for permutation computations A callable C++ library for permutation computations including set stabilizer, in-orbit computations and finding lexicographically least orbit elements, based on bases and strong generating sets (BSGS). -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110716143544.31287.31588.reportbug@zancas.localnet
Re: [ANNOUNCE] dh_splitpackage 0.2.2
On Sun, 05 Jun 2011 18:22:10 +0200, Olivier Berger wrote: > Uh... Maybe I missed the point of this tool which was obvious to many > others, but could you provide a typical use case for using it ? I assume it is a matter of not wanting to manually maintain $pkg.install files. Here is an except from d/rules for darktable. PLUGIN_EXCLUDES=$(patsubst %,-X%, \ $(notdir $(shell cat $(wildcard debian/darktable-plugins-*.install override_dh_install: dh_install -pdarktable $(PLUGIN_EXCLUDES) dh_install --remaining-packages The top level directory /usr/lib/darktable is listed in darktable.install, but any files under that installed in other packages will be excluded. As usual with such "cleverness", one can question the tradeoff of fragility versus ease of maintenance. David -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87vcwk2f4k.fsf@zancas.localnet
Re: Ok to use upstream doumentation as-is (i.e. not regenerate)?
On Sun, 05 Jun 2011 16:49:14 +0200, Joachim Breitner wrote: Non-text part: multipart/signed > > if I do regenerate the files for shipping (or don’t ship them in the > binary packages), is it ok to leave the upstream-generated files in > the .orig.tar.gz, even though I have no hard guarantee that they are > built from these sources (assuming I have no reason to assume that they > are not), or should every such .orig.tar.gz be re-packaged and stripped > of all generated files? > Personally I think overwriting files in .orig.tar.gz is does not require re-packing. If it did, then every package that calls autoreconf or equivalent is buggy. Saving the extra complication of saving and restoring files (or just deleting the generated ones in the clean step) doesn't seem to me be worth the losing pristine original source. d pgpPPkTHziA6L.pgp Description: PGP signature
Re: Wanted: maintainer for git's emacs support
On Fri, 18 Feb 2011 21:18:38 -0600, Jonathan Nieder wrote: > None of the current Debian git maintainers seem to use emacs. This > means git's emacs support[1] does not get as much care as it deserves: > see for example bugs #611936, #611931, #611932, #611933, #611934, > #577834, and #611935. FWIW, if I was going to put energy into something related to git and emacs, it would be into magit [1], which I use daily, and which is also pretty out of date in Debian. d [1] http://philjackson.github.com/magit/index.html -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87aahsm69q.fsf@zancas.localnet
Bug#614064: ITP: libconvert-ytext-perl -- encode utf8 string into rfc2822 localpart
Package: wnpp Severity: wishlist Owner: David Bremner Package name: libconvert-ytext-perl Version : 0.1.2 Upstream Author : David Bremner (i.e. me) URL : http://search.cpan.org/dist/Convert-YText/ License : Same as perl (Artistic or GPL1+) Programming Lang: Perl Description : module to encode utf8 strings into rfc2822 localpart Convert::YText converts strings to and from "YText", a format inspired by xtext (defined in RFC1894), and the MIME base64 and quoted-printable types (RFC 1394). The main goal is encode a UTF8 string into something safe for use as the local part in an internet email address (RFC2822). . By default spaces are replaced with "+", "/" with "~", the characters "A-Za-z0-9_.-" encode as themselves, and everything else is written "=USTR=" where USTR is the base64 (using "A-Za-z0-9_." as digits) encoding of the unicode character code. The encoding is configurable. I'm uploading this to Debian because I'm using it for some Debian infrastructure hacking. I'll be relying on the good folks in pkg-perl to help me maintain it. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110219123744.24875.42545.reportbug@zancas.localnet
Bug#608669: ITP: geiser -- generic Emacs/Scheme interaction mode
Package: wnpp Severity: wishlist Owner: David Bremner * Package name: geiser Version : 0.1 Upstream Author : Jose A. Ortega Ruiz * URL : http://www.nongnu.org/geiser/ * License : BSD Programming Lang: Emacs Lisp Description : generic Emacs/Scheme interaction mode Geiser features an enhanced REPL and a set of minor modes improving Emacs' basic scheme major mode. The main functionalities provided are: - Evaluation of forms in the namespace of the current module. - Macro expansion. - File/module loading. - Namespace-aware identifier completion (including local bindings, names visible in the current module, and module names). - Autodoc: the echo area shows information about the signature of the procedure/macro around point automatically. - Jump to definition of identifier at point. - Access to documentation (including docstrings when the implementation provides it). - Listings of identifiers exported by a given module. - Listings of callers/callees of procedures. - Rudimentary support for debugging (list of evaluation/compilation error in an Emacs' compilation-mode buffer). -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110102145139.821.58115.report...@zancas.localnet
Re: Question: How is debian-policy during freeze?
> > This is the link: > > > > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=562560 > > > You filed that bug at "normal" severity. That does not indicate a > non-working package, so it stays below the radar… I believe Patrick Schoenfeld downgraded the bug. http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=12;bug=562560#12 d -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/874oa3htqj@zancas.localnet
Re: Bug#603672: ITP: navi2ch -- 2ch Navigator for Emacs
On Tue, 16 Nov 2010 18:23:46 +0900, Takaya Yamashita wrote: > > * Package name: navi2ch > Version : 1.8.3 > Upstream Author : Taiki SUGAWARA > * URL or Web page : http://navi2ch.sourceforge.net/ > * License : GPL2 > Description : 2ch Navigator for Emacs > Please provide more information, for example a proposed long description. I guess 2ch is not so well known outside of Japan. All the best, David -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/8762vxbo69@zancas.localnet
Re: Thinking about bundles
On Sat, 18 Sep 2010 21:29:29 +0200, Raphael Hertzog wrote: > In the article, I mentionned that bundling unrelated software is not a > good idea in general (mainly because there's no common software > version to use). > > So I think that we should not create any infrastructure to make it > even easier to create those bundles. Well, OK, I see your point. But what should we do about e.g. tiny perl modules. My/our impression was that ftp-master was not keen on having many small packages. For example, libcatalyst-modules-perl has installed size of 1468k, but bundles 81 modules. On average then, these would have installed size less than 20k if unbundled. All the best, David -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87aanedd6z@rocinante.cs.unb.ca
Possible gpg smartcard group buy.
Is there any interest in a a group buy of v2 GPG smartcards with delivery to take place at debconf in NYC? The pricing from http://shop.kernelconcepts.de/product_info.php?products_id=42 is as follows (in Euros, including taxes) 1 16.40, 2-5 15.40, 5-10 14.40, 10+ 13.90 You will need a reader as well, these start at around 20 Euros. Another option is the integrated reader and smartcard "crypto-stick" for 49 euros. If you are interested, send me a gpg-signed email by July 16th. Volunteers to accept delivery in US or in EU (and bring to debconf) also welcome. David PS. There is a (so far not too interesting) wiki page at http://wiki.debconf.org/wiki/Debconf10/Unofficial/SmartCardBuy pgpLsyw19P2Du.pgp Description: PGP signature
Re: git and quilt
On Mon, 08 Feb 2010 09:26:14 +1100, Ben Finney wrote: > With Bazaar, one doesn't need to rebase to achieve this. The ‘loom’ > plugin allows for tracking changes against upstream revisions, while > *preserving* the history of changes, and generating tidy change sets to > feed back upstream (or, in our use case of interest, to use as Quilt > patches). As was already mentioned, topgit is not perfect (it basically needs a little polishing, and the history of patch branches gets messy from many merges), but for people who don't want to switch to bzr, it provides essentially the same functionality as bzr loom or (AIUI) hg patch queues. d -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: RFC: convenience copy of cddlib
Tim Abbott wrote: >On Mon, 30 Nov 2009, Francesco P. Lovergine wrote: >> > >> > 1) patch the debian cddlib package to produce a third library, >> >libcdd_gmp (or whatever) that can be linked together with >> >libcdd. This basically migrates the polymake abi changes to the >> >debian package, and maybe eventually upstream. >Do you know whether the polymake developers have contacted upstream to try >to get their changes merged into upstream cddlib? I believe not. >I'm not enthusiastic about changing the library ABI in Debian in a >way that isn't eventually going upstream. I guess I was thinking about adding a new library in addition to the existing ones. Frankie pointed to some linker tricks that might make it possible to have a wrapper library that renames symbols as necessary. This library could be private to the polymake package. I'm still a little fuzzy on how that would work, and how horrible it would be. There is also a small patch (apparently for re-entrancy) that hasn't been pushed upstream yet, but probably could be. I'm working through the somewhat larger diffs to lrslib (also mainly about re-entrancy), and then I can forward the CDD patch upstream if you like, after I stare at it a bit more. cdd.diff Description: Binary data
Re: Bug#549417: ITP: coinor-bcp -- a framework for constructing parallel branch-cut-price algorithms for mixed-integer linear programs
Soeren Sonnenburg wrote: >* Package name: coinor-bcp > Version : 1.2.2 > Upstream Author : Common Public License 1.0 I guess that is not right :) > Description : a framework for constructing parallel branch-cut-price algorithms for mixed-integer linear programs Are you aware that BCP is in maintenance only mode? Lazlo Ladanyi, the actual upstream author, told me that he will look at bug reports, but there won't be any new feature releases. I'm not sure that means it should not be packaged for Debian, but I thought you should know. d -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Bug#544035: RFH: stlport5.2 -- STLport C++ class library
Can anyone explain if/why stlport is still useful? Given the low popcon, and small number of rdepends, could this be a candidate for removal? all the best, David -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#540065: ITP: libsynthesis -- library for SyncML-DS (SyncML Data Sync) clients
Package: wnpp Severity: wishlist Owner: David Bremner * Package name: libsynthesis Version : 3.0.28+git1+cc01b66 Upstream Author : * URL : http://www.synthesis.ch/indefero/index.php/p/libsynthesis/ * License : LGPL2.1 or LGPL3 (with some BSD) . Unless noted otherwise, all files are dual-licensed (LICENSE.LGPL-2.1) and 3.0 (LICENSE.LGPL-3). . Files in the following directories are under a different license: src/expat : public domain (src/expat/copying.txt) doc, src/sysync_SDK : BSD (LICENSE.BSD) src/syncml_tk : BSD-like license (src/syncml_tk/opensource_license.txt) src/zlib: BSD-like (src/zlib/README) Programming Lang: C++, C Description : library for SyncML-DS (SyncML Data Sync) clients The Synthesis SyncML engine supports SyncML versions 1.0, 1.1 and 1.2 including complex features like data filtering, suspend & resume, vCard/vCalendar format conversion in a way completely transparent to the user of the library. This package is a build-dependency for syncevolution (ITP#404942). -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: RFC: DEP-3: Patch Tagging Guidelines
At Fri, 17 Jul 2009 09:00:50 +0200, Guido Günther wrote: > On Wed, Jul 08, 2009 at 07:24:20PM +0100, James Westby wrote: > > Guido Günther wrote: > > > Which isn't a problem on patch-queue branches since you either can > > > recreate them anytime from what's in debian/patches or simply ammend the > > > commit. They're supposed to be rebased frequently anyway. > > > That's not true in my opinion. It would tend to be hostile to people who > > would like to collaborate on the patches wouldn't it? > > Isn't this a question on how you lay out your workflow? The patch-queue > branches are basically a tool that eases managing patches that end up in > debian/patches while retaining the merge capabilities of git (e.g. when > forwarding to new upstream versions, etc.) so there's not even a need to > push them into remote repos - you do have all the information on master > to recreate the patch-queue branch at any time. At least with topgit, patch branches are meant to be pushed and pulled, and use merge rather than rebase for just this reason. This makes the history ugly, but does facilitate the kind of collaboration James alluded to. I lost track of what the global point of this subthread was, but I did think a bit about DEP-3 and topgit, and it seems not particularly problematic since there is some header file .topmsg that already contains subject/signed-off-by headers, and is inserted into the exported patches. I guess it should be not hard to to add more headers. d -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Running a 32bits on debian amd64 system
At Wed, 15 Jul 2009 10:24:06 +0200, Mathieu Malaterre wrote: > > On Mon, Jul 13, 2009 at 5:41 PM, Cyril Brulebois wrote: > > Which obviously hadn't been updated in *years*. RT*appropriate*FM. > Would you be kind enough to actually quote the document (URL) which > you call 'appropriate' As several people already pointed out, 1) schroot is most likely the answer to your original question. It has reasonable docs included with it. 2) debian-devel is not the right venue for this discussion. Thanks for not pursuing the question of who was rude to whom or did or did not read the right thing any further, at least on this list. All the best, d -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Bug#531221: okular: Arbitrarily enforces DRM
Harald Braumann wrote: >[1 ] >On Sun, 31 May 2009 14:19:12 +0200 >Michael Banck wrote: >> I like the advisory note somebody else proposed, i.e. "The author said >> you shouldn't do this, do you want to do this anyway?". Whether or >> not that dialog could get permanently ignored by the user could be >> configurable. >I can't think of many dialogs that would be more useless than asking the >user if he wants the software to forbid him to do what he asks it to do. Like the following, you mean? dulcinea:~/tmp % rm * zsh: sure you want to delete all the files in /home/bremner/tmp [yn]? d -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#529094: ITP: nauty -- graph isomorphism testing library, with command line tools
Package: wnpp Severity: wishlist Owner: David Bremner * Package name: nauty Version : 2.4beta7 Upstream Author : Brendan McKay * URL : http://cs.anu.edu.au/~bdm/nauty/ * License : non-free/pacifist. See below. Programming Lang: C Description : graph isomorphism testing library, with command line tools nauty (no automorphisms, yes?) is a set of procedures for determining the automorphism group of a vertex-coloured graph. It provides this information in the form of a set of generators, the size of the group, and the orbits of the group. It is also able to produce a canonically-labelled isomorph of the graph, to assist in isomorphism testing. nauty is a build dependency of polymake (ITP 461976) License is as follows: Copyright (1984-2009) Brendan McKay. All rights reserved. Permission is hereby given for use and/or distribution with the exception of sale for profit or application with nontrivial military significance. You must not remove this copyright notice, and you must document any changes that you make to this program. This software is subject to this copyright only, irrespective of any copyright attached to any package of which this is a part. Absolutely no guarantees or warranties are made concerning the suitability, correctness, or any other aspect of this program. Any use is at your own risk. The above does not apply to the file planarity.c, which is copyright to the Magma project and distributed with nauty by permission. Planarity.c says the following: /* planarity.c - code for planarity testing of undirected graphs. * Method of Boyer and Myrvold, programmed by Paulette Lieby. * The copyright of this program is owned by the Magma project. * Distributed with nauty by permission. ***/ I expect to make 3 binary packages: nautycommand line tools and manuals libnauty-devstatic lib and headers libnauty0 shlib -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#528925: ITP: bliss -- tool for computing automorphism groups and canonical labelings of graphs
Package: wnpp Severity: wishlist Owner: David Bremner * Package name: bliss Version : 0.50 Upstream Author : Tommi Juntilla and Petteri Kaski * URL : http://www.tcs.hut.fi/Software/bliss/index.shtml * License : GPL2 Programming Lang: C++ Description : tool for computing automorphism groups and canonical labelings of graphs Bliss is a backtracking algorithm based on individualization and refinement for labeling a graph. Data structures, subroutines, and pruning heuristics especially for fast handling of large and sparse graphs are provided. This package provides the command line tool bliss; a C++ and C API is also available. There is also a libbliss-dev which changes the last line of the long description. At the moment I propose not to create a shared library package since upstream doesn't make one, and in the short term there won't be any rdepends in debian. I could be convinced otherwise of course. This package will be maintained under the umbrella of the debian-science team. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Breaking /emul/ia32-linux for squeeze
Mike Hommey wrote: >On Mon, Mar 16, 2009 at 03:21:44PM +0100, Marco d'Itri wrote: >> I think it would be very helpful if somebody could summarize why a >> multiarch system is useful, except for the obvious case of installing >> proprietary i386 software on amd64 systems. >s/proprietary// ; there you have your obvious case. To hopefully amplify Mike's point, I currently have a 32bit chroot to run mozart-oz (needed for $WORK) on my amd64 desktop. I'm sure there are many other examples. Setting up a chroot is a barrier for many users (even if schroot and debootstrap make it fairly easy in practice on Debian). Of course all software should become 64bit clean eventually, but here we are. I suppose some motivated person could survey all the software in the archive that is present on i386 but not on amd64. All the best David -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Requirement for a “proper manpage” for every command
At Mon, 2 Mar 2009 13:29:06 -0600, Gunnar Wolf wrote: > > Hmh, this could even be promoted as a "best packaging practice". Many > authors do ship properly-formatted --help entries, and our > hand-generated manpages can often linger behind the truth. Any strong > opinions against? Not to rehash an old wontfix :-), but since you ask... Only a minor comment, that help2man could be a bit more flexible about e.g. accepting input on stderr. See the discussion on #138752. I'm not sure how many packages fail to follow "the GNU standards document" in terms of how they print their help output, but it seems like a potential source of irritation. Of course, if I'm missing something about Debian policy, consider me shushed. d -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#515295: ITP: libsyntax-highlight-engine-simple-languages-perl -- collection of syntax definition subclasses for Syntax::Highlight::Engine::Simple
Package: wnpp Severity: wishlist Owner: David Bremner * Package name: libsyntax-highlight-engine-simple-languages-perl Version : To be decided. Upstream Author : Sugama Keita * URL : http://search.cpan.org/dist/Syntax-Highlight-Engine-Simple/ * License : GPL|Artistic Programming Lang: Perl Description : collection syntax definition subclasses for Syntax::Highlight::Engine::Simple Syntax::Highlight::Engine::Simple provides a framework for generating coloured HTML from source code and similar text using regular expressions, controlled by cascading stylesheets (CSS). This package provides subclasses definining syntax for concrete languages. The current version includes . Syntax::Highlight::Engine:Simple::Perl Syntax::Highlight::Engine:Simple::HTML Comments from packager: - I expect/hope to include classes from upstream for Java/PHP/C++ before too long, and maybe collect some others. - I'm not 100% sure about the versioning. It might make sense for this to be a native package (as e.g. libcatalyst-modules-perl which it is modelled on). - The base package ITP BTS #515505. -- System Information: Debian Release: 5.0 APT prefers testing APT policy: (900, 'testing') Architecture: i386 (i686) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#515105: ITP: libsyntax-highlight-engine-simple-perl -- Provide CSS based highlighting for source code and similar text
Package: wnpp Severity: wishlist Owner: David Bremner * Package name: libsyntax-highlight-engine-simple-perl Version : 0.8 Upstream Author : Sugama Keita . * URL : http://search.cpan.org/dist/Syntax-Highlight-Engine-Simple/ * License : GPL/Artistic (Same as Perl) Programming Lang: Perl Description : Provide CSS based highlighting for source code and similar text This is a syntax highlighting. It generates an HTML fragment by marking up the input string with span tags according the given rules. Colouring or other highlighting is then controlled via CSS. Configuration for particular source languages can be done by subclassing. . Compared to other source highlighting solutions, this one is light-weight, and suitable for use in perl programs. This package will be maintained by the pkg-perl team. -- System Information: Debian Release: 5.0 APT prefers testing APT policy: (900, 'testing') Architecture: amd64 (x86_64) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#509953: ITP: lp-solve-java -- library providing Java bindings for lp-solve, via JNI
Package: wnpp Severity: wishlist Owner: David Bremner X-Debugs-CC: este...@v7w.com, r...@debian.org, ani...@debian.org * Package name: lp-solve-java Version : 5.5.0.13 Upstream Author : Juergen Ebert * URL : http://lpsolve.sourceforge.net * License : LGPL Programming Lang: C++, Java Description : library providing Java bindings for lp_solve, via JNI lp_solve is a linear(integer) programming solver based on the revised simplex method and the Branch-and-bound method for the integers. This library is designed to provide easy access to the lp_solve API from Java. It consists of two main parts: - A Java class library that is used by Java client programs. It gives access to all lp_solve routines through the LpSolve class. - A native library written in C++, also called 'stub' library, that uses the JNI (Java Native Interface) API to translate Java method calls into calls to the corresponding routines of the lp_solve library. Comments: - I would be quite happy if someone (lp_solve maintainers?) wanted to take this over, or co-maintain - Alternatively, I would probably join pkg-java - Preliminary packaging (that has many policy problems, but does apparently) can be found at http://pivot.cs.unb.ca/git/?p=lp-solve-java.git;a=summary or clone from git://pivot.cs.unb.ca/git/lp-solve-java.git -- System Information: Debian Release: 5.0 APT prefers unstable APT policy: (900, 'unstable') Architecture: i386 (i686) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Bug#509242: ITP: lensfun -- LensCorrection editor plugin
Hi Mark; Sounds very interesting. I'm not (yet) a member, but I guess the pkg-phototools team on alioth would welcome you http://pkg-phototools.alioth.debian.org/ Since tehy already maintain e.g. hugin and panorama tools) (I just wanted to beat KiBi to saying that :-) d (manual resend because of pebkac) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#505878: ITP: libfunambol-cpp-client-api -- cross-platform syncml client stack
Package: wnpp Severity: wishlist Owner: David Bremner <[EMAIL PROTECTED]> * Package name: libfunambol-cpp-client-api Version : syncevolution-0.8.1 Upstream Author : Funambol Inc. * URL : http://core.forge.funambol.org * License : AGPL Programming Lang: C++ Description : cross-platform syncml client stack Long description, from web site, needs improvement: --- This SDK allows to integrate a syncml stack in a C++ application on a variety of platforms. Currently, Windows, WinMobile and Linux are actively supported, but you can easily build it on other Unixes or other mobile/embedded platforms. Comments on Licensing: -- Although there continues to be a certain amount of debate about the AGPL, there is at least one [1] AGPL package in main, so for the moment I am going ahead on the assumption that ftp-master will let it in. Comments on upstream sources: - Patrick Ohly maintains a git repo with the official sources, plus some patches. at http://github.com/pohly/funambol-cpp-client-api/tree/master Since my main goal is to get Patrick's Syncevolution packaged, I will probably use Patrick's git repo as upstream. Alternatively I could essentially duplicate Patrick's efforts by starting with pristine upstream and applying the same set of patches. Let me know if people have ideas about the "right way" to proceed. [1] http://packages.debian.org/changelogs/pool/main/y/yocto-reader/yocto-reader_0.9.3/yocto-reader.copyright -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing') Architecture: i386 (i686) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Leverage in licensing discussions (was: [DRAFT] resolving DFSG violations)
At Fri, 7 Nov 2008 00:27:13 +0100, Michelle Konzack wrote: > And as I > have already written, I do not know HOW OpenMoko will solv this problem, > but FreeRunner/OpenMoko or PurpleMagic are not allowd to run in Europe > with Open Source GSM-Firmware. And of course, PurpleMagic has never > respond to my three E-Mails and one Letter. (they are in France) I spent 5 minutes reading the OpenMoko wiki and mailing lists, and it seems to me that they do not have open source firmware for the GSM modem. The reasons given (essentially the fragility of the GSM network) more or less agree with what you write. If this is what you meant to write, it was not successfully communicated to me. David -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug Sprint - Oct 25 to Oct 30 - Register and eat cookies
At Tue, 21 Oct 2008 13:43:01 +0200, Josselin Mouette wrote > Fixing a RC bug means either of: > * Uploading a NMU that fixes the bug to unstable. > * Convincing, with a mail that details the rationale, a release > manager to tag the bug lenny-ignore. > * Convincing, in a similar way, a release manager to remove the > package from lenny. So downgrading bugs to non-RC severity (with appropriate rationale) does not count in the great cookie contest? d -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#501717: ITP: libnet-mac-vendor-perl -- Look up the vendor for a MAC
Matt Zagrabelny wrote: >Package: wnpp >Severity: wishlist >* Package name: libnet-mac-vendor-perl Hi Matt; I noticed you ITP'd 3 perl modules recently. Perhaps you would like to join the debian perl team (http://alioth.debian.org/projects/pkg-perl/) and maintain your modules there. There are many helpful team members who can help you with packaging and uploading. David -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#496938: ITP: libcrypt-generatepassword-perl -- perl module to generate secure random passwords
At Thu, 28 Aug 2008 20:27:44 +0400, Alexander Gerasiov wrote: > > Package: wnpp > Severity: wishlist > Owner: Alexander Gerasiov <[EMAIL PROTECTED]> > > * Package name: libcrypt-generatepassword-perl > Version : 0.03 > > I don't really know is this module is usefull for anybody else, but > it is needed by netams ITP #496636. Hi Alexander; I'm sure you would be welcome to maintain this as part of the Debian perl module packaging team. http://pkg-perl.alioth.debian.org/ Then sponsors come looking for you... As seen on Debconf8 TV :-), it's a great team. David -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
