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
Bug#461976: ITP: polymake -- Tool for algorithmic discrete geometry/topology
Package: wnpp Severity: wishlist Owner: David Bremner <[EMAIL PROTECTED]> * Package name: polymake Version : 2.3 Upstream Author : Ewgenij Gawrilow <[EMAIL PROTECTED]> Michael Joswig <[EMAIL PROTECTED]> * URL : http://www.math.tu-berlin.de/polymake/ * License : GPL Programming Lang: C++, Perl Description : Tool for algorithmic discrete geometry and topology Polymake started out as a tool for the algorithmic treatment of convex polyhedra. By now it also deals with finite simplicial complexes, tight spans of finite metric spaces, polyhedral surfaces, and other mathematical objects. -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.22 (SMP w/2 CPU cores) Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bash Commander package, anybody please
> "Serge" == Serge Vakulenko <[EMAIL PROTECTED]> writes: Serge> Would anybody please create a port for Bash Commander? It Serge> is a traditional GNU bash shell extended with visual Serge> two-panel file browser. Web site is here: Serge> http://bashc.sourceforge.net/ ___ Regards, Serge Vakulenko Hi Serge; Please file an RFP (request for package) bug on package wnpp. It sounds a bit obscure, but if you run "reportbug wnpp" from a shell, it will guide you. All the best, David -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Idea for package name instead of "build" (ITP)
> "Raphael" == Raphael Bossek <[EMAIL PROTECTED]> writes: Raphael> Now I'm looking for a idea how to name the "build" Raphael> package. For my perspective of view is "build" to simple Raphael> to be packaged as it is. My idea was to sue the first Raphael> letters (forename, surname) of the developer, Raphael> e.g. bkbuild. Since it seems to generate makefiles, I suggest Automake :-) But, slightly more seriously "mentioning" Gnu Make might also be a possibility: e.g. gmbuild or mkbuild or makebuild or mfbuild. d -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Idea for package name instead of "build" (ITP)
> "Michael" == Michael Banck <[EMAIL PROTECTED]> writes: >> >> Since it seems to generate makefiles, I suggest Automake :-) >> >> But, slightly more seriously "mentioning" Gnu Make might also >> be a possibility: e.g. gmbuild or mkbuild or makebuild or >> mfbuild. Michael> It's unclear to me what your answer has to do with the Michael> question. AFAICT, Raphael was asking for feedback on how Michael> to name some random build system with the pretty generic Michael> name `build', and you recommended some alternatives Michael> instead. Sorry, I guess I was not very clear. I meant to suggest that since the build system called "build" is really a makefile generator for GNU Make, that it might be helpful if the Debian package name could hint at that fact. The rest of my message was suggestions for names. Upon reflection, not only was the idea not so well expressed, but relationship with GNU Make could be better expressed in the short description. OK, I think I have generated enough noise on this issue. David -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#486671: ITP: ntl -- C++ library for arbitrary precision integers, vectors, matrices, and polynomials
Package: wnpp Severity: wishlist Owner: David Bremner <[EMAIL PROTECTED]> * Package name: ntl Version : 5.4.2 Upstream Author : Victor Shoup <[EMAIL PROTECTED]> * URL : http://www.shoup.net/ntl * License : GPL Programming Lang: C++ Description : arbitrary precision numbers, vectors, matrices and polynomials Vcs-Git: git://git.debian.org/git/debian-science/packages/ntl Vcs-Browser: http://git.debian.org/?p=debian-science/packages/ntl.git (from the web site) NTL provides algorithms for: * arbitrary length integer arithmetic and arbitrary precision floating point arithmetic; * polynomial arithmetic over the integers and finite fields including basic arithmetic, polynomial factorization, irreducibility testing, computation of minimal polynomials, traces, norms, and more; * lattice basis reduction, including very robust and fast implementations of Schnorr-Euchner, block Korkin-Zolotarev reduction, and the new Schnorr-Horner pruning heuristic for block Korkin-Zolotarev; * basic linear algebra over the integers, finite fields, and arbitrary precision floating point numbers. There is some very rough (i.e. at the moment only the -dev package has content) packaging in the debian-science repo; see above for URLs. Co-Maintainers welcome. -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.24-1-686 (SMP w/2 CPU cores) Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
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: 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
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: 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
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: 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
Bug#429688: ITP: libpushmi-perl -- Subversion repository replication tool
Package: wnpp Severity: wishlist Owner: David Bremner <[EMAIL PROTECTED]> * Package name: libpushmi-perl Version : 0.994.0 Upstream Author : bradfitz <[EMAIL PROTECTED]> * URL : http://code.bestpractical.com/project/Pushmi * License : Apache 2.0 Programming Lang: Perl Description : Subversion repository replication tool Pushmi provides a mechanism for bidirectionally synchronizing Subversion repositories. The main difference between Pushmi and other replication tools is that Pushmi makes the "slave" repositories writable by normal Subversion clients. Discussion: Depends: libversion-perl, librunapp-perl, libsvn-core-perl, svk (>= 2.0.0), libapp-cli-perl (>= 0.06), libyaml-syck-perl, liblog-log4perl-perl, memcached This would need Runapp.pm, locally packages as librunapp-perl. I will submit a seperate ITP for that, all going as planned. -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.21-1-686 (SMP w/2 CPU cores) Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#430686: ITP: libapp-control-perl -- Perl module for apachectl style control of another script or
Package: wnpp Severity: wishlist Owner: David Bremner <[EMAIL PROTECTED]> * Package name: libapp-control-perl Version : x.y.z Upstream Author : Name <[EMAIL PROTECTED]> * URL : http://www.example.org/ * License : (GPL, LGPL, BSD, MIT/X, etc.) Programming Lang: (C, C++, C#, Perl, Python, etc.) Description : Perl module for apachectl style control of another script or executable App::Control is a simple module to replicate the kind of functionality you get with apachectl to control apache, but for any script or executable. There is a very simple OO interface, where the constructor is used to specify the executable, command line arguments, and pidfile, and various methods (start, stop, etc.) are used to control the executable in the obvious way. The module is intended to be used in a simple wrapper control script. Currently the module does a fork and exec to start the executable, and sets the signal handler for SIGCHLD to 'IGNORE' to avoid zombie processes. Comments: This is needed by librunapp-perl, to be ITPed soon, and (indirectly) libpushmi-perl, ITP#429688 -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.21-1-686 (SMP w/2 CPU cores) Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#431763: ITP: librunapp-perl -- A generic module to configure and run web-applications
Package: wnpp Severity: wishlist Owner: David Bremner <[EMAIL PROTECTED]> * Package name: librunapp-perl Version : 0.13 Upstream Author : Chia-liang Kao <[EMAIL PROTECTED]> * URL : http://search.cpan.org/~clkao/RunApp-0.13 * License : Perl (GPL/Artistic) Programming Lang: Perl Description : A generic module to configure and run web-applications RunApp streamlines the process for configuring applications that require one or more web servers and/or other daemons, during development or deployment. It builds the config files required by the services from the $config hash, such as apache's httpd.conf. Comments from would-be packager: This is a build dependency for pushmi, ITP #429688 -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (900, 'testing'), (300, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.20 (PREEMPT) Locale: LANG=en_CA, LC_CTYPE=en_CA (charmap=ISO-8859-1) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#493233: ITP: libmail-thread-perl -- library for threading email by In-Reply-To and References
Package: wnpp Severity: wishlist Owner: David Bremner <[EMAIL PROTECTED]> * Package name: libmail-thread-perl Version : 2.55 Upstream Author : Simon Cozens <[EMAIL PROTECTED]> * URL : http://search.cpan.org/dist/Mail-Thread/ * License : Perl (Artistic/GPL) Programming Lang: Perl Description : library for threading email by In-Reply-To and References The Mail::Thread module implements something relatively close to Jamie Zawinski's mail threading algorithm, as described by http://www.jwz.org/doc/threading.html. This algorithm is based on following References and In-Reply-To headers, and is able to deal with not having all of the messages in a thread. It will be maintained under the loving care of the pkg-perl team. -- 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]
Bug#493255: ITP: libemail-thread-perl -- provide threading for Email::Simple objects based on Mail::Thread
Package: wnpp Severity: wishlist Owner: David Bremner <[EMAIL PROTECTED]> * Package name: libemail-thread-perl Version : 0.711 Upstream Author : Ian Truskett <[EMAIL PROTECTED]> * URL : http://emailproject.perl.org/wiki/Email::Thread * License : Perl (Artistic/GPL) Programming Lang: Perl Description : library providing threading for Email::Simple objects This class is a wrapper for Mail::Thread that allows it to work with Email::Simple objects. The combination of the two libraries allows collections of Email::Simple objects to be organized into threads by References and In-Reply-To headers. This package will be maintained with the pkg-perl team. See also ITP#493233 for Mail::Thread -- 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: 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]
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 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: 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]
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: 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#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
Bug#440914: ITP: sketch -- produce 3D line drawings from scene description language
Package: wnpp Severity: wishlist Owner: David Bremner <[EMAIL PROTECTED]> * Package name: sketch Version : 0.2.9 Upstream Author : Eugene Ressler * URL : http://www.frontiernet.net/~eugene.ressler * License : Unknown "Copyleft" Programming Lang: C Description : produce 3D line drawings from scene description language Sketch is a simple system for producing line drawings of three-dimensional objects and scenes. Sketch is intended to produce finely wrought, mathematically-based illustrations with no extraneous detail and be able to easily overlay TeX math and text. The input language is reminiscent of PSTricks, so will be easy to learn for current PSTricks users. It generates either PSTricks or TikZ/PGF code as output. LICENSING NOTES: On the website it states, I've developed some tools while writing a textbook. They're good enough to get real work done, so I'm offering them free under Copyleft. But there seems to be no explicit licensing information in the source. Obviously I need to figure this out before the package can be considered for inclusion in Debian. NAME NOTES: There was another package named sketch; it seems to be gone now. If this is problematic, an alternative name could be sketch3d -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.22 (SMP w/2 CPU cores) Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#452557: ITP: bibutils -- interconvert various bibliographic data formats
Package: wnpp Severity: wishlist Owner: David Bremner <[EMAIL PROTECTED]> Package name: bibutils Version : 3.39 Upstream Author : Chris Putnam <[EMAIL PROTECTED]> URL : http://www.scripps.edu/~cdputnam/software/bibutils/bibutils.html Programming Lang: C License : GPL2 Description : interconvert various bibliographic data formats From the homepage: The bibutils program set interconverts between various bibliography formats using a common MODS-format XML intermediate. For example, one can convert RIS-format files to Bibtex by doing two transformations: RIS->MODS->Bibtex. By using a common intermediate for N formats, only 2N programs are required and not N²-N. These programs operate on the command line and are styled after standard UNIX-like filters. -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.22 (SMP w/2 CPU cores) Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#454469: ITP: lrslib -- enumerate vertices and extreme rays of a convex polyhedron
Package: wnpp Severity: wishlist Owner: David Bremner <[EMAIL PROTECTED]> * Package name: lrslib Version : 4.2b Upstream Author : David Avis <[EMAIL PROTECTED]> * URL : http://cgm.cs.mcgill.ca/~avis/C/lrs.html * License : GPL 2+ Programming Lang: C Description : Enumerate vertices and extreme rays of a convex polyhedron A convex polyhedron is the set of points satisfying a finite family of linear inequalities. The study of the vertices and extreme rays of such systems is important and useful in e.g. mathematics and optimization. In a dual interpretation, finding the vertices of a (bounded) polyhedron is equivalent to finding the convex hull (bounding inequalities) of an (arbitrary dimensional) set of points. Lrs (lexicographic reverse search) has two important features that can be very important for certain applications: it works in exact arithmetic, and it consumes memory proportional to the input, no matter how large the output is. -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.22 (SMP w/2 CPU cores) Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
wdg-html-validator versus w3c-html-validator
Hi All; I noticed that wdg-html-validator had been orphaned for more than a year, and since I use the offline validator script, I filed an ITA (http://bugs.debian.org/390833). Now that I look at the logistics of packaging it (download 5 files from 5 places, make .orig.tar.gz by hand, no watch file) and the fact that it includes CGI, I am a little less enthusiastic (this is emphatically not a criticism of Aurelien Jarno's packaging work). So, some questions: 1) If there is another good offline (i.e. shell command) html validator in Debian? weblint-perl for (non)-example does not support xhtml. 2) Are there any compelling advantages to the cgi validator provided by wdg-html-validator versus w3c-html-validator? The packages have about the same popcon counts. If the answer to 1=yes, 2=no, probably I will re-orphan. If 1=no, 2=no, I might consider repackaging just the offline validator. Thanks for any feedback, David -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: wdg-html-validator versus w3c-html-validator
>>>>> "Ben" == Ben Hutchings <[EMAIL PROTECTED]> writes: Ben> On Fri, 2007-12-14 at 10:45 +0100, David Bremner wrote: >> >> 1) If there is another good offline (i.e. shell command) html >> validator in Debian? weblint-perl for (non)-example does not >> support xhtml. Ben> nsgmls (from the sp package) can parse and validate *any* Ben> SGML document (possibly limited by character set support). Ben> Something like: n Ben> SGML_CATALOG_FILES=/usr/share/sgml/declaration/xml.soc \ Ben> SP_CHARSET_FIXED=YES SP_ENCODING=XML nsgmls -s -wxml Ben> index.html Ben> should work for XML. /usr/share/doc/sp/xml.htm has more Ben> information. Right, I think all of the tools under discussion are wrappers for nsgmls. wdg-html-validator uses the version in opensp. I think there is some value for many debian users in a more friendly front end. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#458394: ITP: wdg-offline-validator -- command line html validator (front-end for nsglms)
Package: wnpp Severity: wishlist Owner: David Bremner <[EMAIL PROTECTED]> Package name: wdg-offline-validator Version : 1.2.2 Upstream Author : Liam Quinn <[EMAIL PROTECTED]> URL : http://www.htmlhelp.com/tools/validator/offline License : GPL or Artistic Programming Lang: Perl Description : command line html validator (front-end for nsglms) This package provides the command validate, which uses a validating SGML parser to test for conformance to HTML standards. Packaging Notes: After a somewhat inconclusive discusion on debian-devel [1] I decided to go ahead and package the command line html validator from wdg-html-validator seperately, and drop my ITA [2]. Even if someone does decide to make a new version of wdg-html-validator, there is no actual files shared between the two packages other than the one script 'validate', which could then be dropped from the cgi+html package. I could use some help with the long description... [1] http://news.gmane.org/find-root.php?message_id=%3c0tbq8thaoc.wl%25bremner%40pivot.cs.unb.ca%3e [2] http://bugs.debian.org/390833 -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.22 (SMP w/2 CPU cores) Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Future Debian package candidate web pages: present and future
> "Sebastian" == Sebastian Pipping <[EMAIL PROTECTED]> writes: Sebastian> also a sync with BTS can be manually invoked now, link Sebastian> at the top. check out the new version here: Sebastian> http://debian.binera.de/wnpp/ Looking better all the time. I would really like some (approximate) popcon data myself, especially for orphaned packages. But I'm like, just this guy you know? david -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Future Debian package candidate web pages: present and future
>>>>> "Sebastian" == Sebastian Pipping <[EMAIL PROTECTED]> writes: Sebastian>> David Bremner wrote: >> I would really like some (approximate) popcon data myself, >> especially for orphaned packages. Sebastian> would be cool, yes. i don't have any clue to do this Sebastian> yet. if you do please share your thoughts with me to Sebastian> speed the thing up. deal? :-) As far as I understand it (and maybe somebody more informed can correct me), there is currently no fancy interface (SOAP) to the data on popcon.debian.org On the other hand, it does not change that quickly, so grabbing a copy once a week should be reasonable. http://qa.debian.org/popcon.php?package=whatever obviously has access to the data, so maybe someone on the qa team can comment. >> But I'm like, just this guy you know? Sebastian> sorry, i'm not sure what you mean. Hitchhikers Guide to the Galaxy reference. (http://en.wikipedia.org/wiki/Zaphod_Beeblebrox). I just wanted to emphasise my bystander/dabbler status. d -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
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
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: 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
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: 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
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
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
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#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#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
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
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
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
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
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
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: 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: 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: 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
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
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: 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
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
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
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
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: [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
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: [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
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: 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: 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: 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
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
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#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
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
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: 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: 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: 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: 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:
> 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: 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: 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
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
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
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: 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
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: 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: 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.
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: 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
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
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: 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
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: 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: 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: 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: 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
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-
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#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#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-
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: 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
