Package: wnpp
Severity: wishlist
Owner: Victor Seva
* Package name: lua-redis
Version : 2.0.4
Upstream Author : Daniele Alessandri
* URL : https://github.com/nrk/redis-lua
* License : MIT/X11
Programming Lang: lua
Description : pure Lua client library
Do you also plan to get rid of these? They appear to be designed to
block auto-removal of installed linux-image-* and linux-header-*
packages.
/etc/kernel/postinst.d/apt-auto-removal
/etc/apt/apt.conf.d/01autoremove-kernels
--
bye,
pabs
http://wiki.debian.org/PaulWise
--
To UNSUBSCRIBE, emai
I'd like to stop the binary packages built from linux providing the
following virtual packages:
* linux-image
As explained in #724569, any relations on a virtual package prevent
auto-removal of all providing packages, so in this case linux-image-*
packages must be manually removed to avoid fillin
Package: wnpp
Severity: wishlist
Owner: Zlatan Todoric
* Package name: repetier-host
Version : 0.90b
Upstream Author : Repetier
* URL : https://github.com/repetier/Repetier-Host
* License : ASL2.0
Programming Lang: C#
Description : Host controller for
RepRap (Prusa Mendel, MendelMax, Huxley, Tantillus...), Ultimaker,
Makerbot, Lulzbot AO-100, TAZ, MakerGear M2, Rostock, Mach3, Bukobot and
lots more. And even DLP printers.
As it is written on their website.
It will be added to long description (thanks for suggestion!).
Cheers,
zlatan
On Thu
On Thursday 26 September 2013 02:21:00 Zlatan Todoric wrote:
> Package: wnpp
> Severity: wishlist
> Owner: Zlatan Todoric
>
> * Package name: slic3r
> Version : 0.9.10b
> Upstream Author : Alessandro Ranellucci
> * URL : http://slic3r.org/
> * License : AGPLv3
Package: wnpp
Severity: wishlist
Owner: Zlatan Todoric
* Package name: slic3r
Version : 0.9.10b
Upstream Author : Alessandro Ranellucci
* URL : http://slic3r.org/
* License : AGPLv3
Programming Lang: C++, Perl
Description : Tool to convert a digital 3D
Hi,
On Wed, Sep 25, 2013 at 09:39:12AM +0200, Dominik George wrote:
> I think I will send a first patch against unar's Vcs-Git in the course
> of today. Besides, I would really like to hear the unar maintainer's
> thoughts ☺.
I'm one of the unar package maintainers and would be happy to include
a
On 09/25/2013 09:00 PM, Daniel Pocock wrote:
> Is there any convenient way that upstream can generate a clean tarball
> with qmake? In general, is it sufficient to work with a
> github-generated tarball for the tag on a qmake project?
Not tested - and I havent used qmake for some longish time, b
Hi Charles (and everyone else),
On Sun, 22 Sep 2013 12:28:11 +0900, Charles Plessy wrote:
> Hi Paul, FTP team and everybody,
> first, let me underline that if the FTP team wants to disuss and
> amend its decision, I will be happy to participate.
> I think that the only good solution is to enga
On Wed, Sep 25, 2013 at 9:06 PM, Sune Vuorela wrote:
> Unless for autotools projects where you might want to store pregenerated
> files in the tarball, I've never seen the reason for make dist.
For several of my (admittedly autotools) upstreams I add git2cl in the
dist-hook and now that I have pa
On Wed, Sep 25, 2013 at 07:06:04PM +, Sune Vuorela wrote:
> For all my qmake and cmake based projects, neither that has a make dist,
> I've asked my VCS for a tarball of the tag and blessed that one as 'the
> release'.
+1
Anecdotally, one of my upstreams has a broken tarball which is a git
ex
On Wed, 25 Sep 2013, Adam Borowski wrote:
> On Wed, Sep 25, 2013 at 09:38:18AM -0700, Russ Allbery wrote:
> > Thorsten Glaser writes:
> > > Russ Allbery debian.org> writes:
> > Programs that don't check the return status of functions that they think
> > won't ever fail are a bit of a pet peeve of
On 2013-09-25, Daniel Pocock wrote:
> qmake doesn't appear to provide a "make dist" facility, at least not the
> way the project is currently configured.
Unless for autotools projects where you might want to store pregenerated
files in the tarball, I've never seen the reason for make dist.
For a
upstream is using qmake for PostBooks
qmake doesn't appear to provide a "make dist" facility, at least not the
way the project is currently configured.
Consequently, upstream tarballs tend to be snapshots of the developer
workspace, in one case, even including things like submodules,
.gitmodule
]] Steve Langasek
> The real rationale is surely that, because facts are *not governed by
> copyright*, any licensing claim over this data is ignorable.
Copyrights are not the any type of «IP» that may require
licensing. Database rights exist in Europe for instance.
--
Tollef Fog Heen
UNIX is
Hi Steve,
On Wed, 25 Sep 2013, Steve Langasek wrote:
On Mon, Sep 16, 2013 at 12:59:11PM +0100, Peter Rice wrote:
On 16/09/2013 11:31, Faheem Mitha wrote:
This is really not Debian-related, except insofar as the software in
question is something that might have been in Debian one day. I t
On Wed, Sep 25, 2013 at 05:02:58PM +0200, Andreas Henriksson wrote:
> Hello!
>
> I intend to drop the iproute transitional packages in Jessie+1.
>
> This message is here to give all 68 packages depending/recommending/suggesting
> the old iproute package time to simply update their dependencies to
Russ Allbery writes:
> Adam Borowski writes:
>> On Wed, Sep 25, 2013 at 09:38:18AM -0700, Russ Allbery wrote:
>>> Programs that don't check the return status of functions that they
>>> think won't ever fail are a bit of a pet peeve of mine, in part
>>> because it would make a lot of sense for lo
On Wed, Sep 25, 2013 at 11:43:22AM +, Thorsten Glaser wrote:
> No, the standard said it would either always fail or never, but independent
> on the input data.
Nope:
| Upon successful completion, crypt() shall return a pointer to the
| encoded string. The first two characters of the returned v
Adam Borowski writes:
> On Wed, Sep 25, 2013 at 09:38:18AM -0700, Russ Allbery wrote:
>> Programs that don't check the return status of functions that they
>> think won't ever fail are a bit of a pet peeve of mine, in part because
>> it would make a lot of sense for localtime() to be able to fail
On Wed, Sep 25, 2013 at 09:38:18AM -0700, Russ Allbery wrote:
> Thorsten Glaser writes:
> > Russ Allbery debian.org> writes:
> Programs that don't check the return status of functions that they think
> won't ever fail are a bit of a pet peeve of mine, in part because it would
> make a lot of sens
Thorsten Glaser writes:
> Russ Allbery debian.org> writes:
>> (consider resource exhaustion errors in the crypt implementation, for
> No, the standard said it would either always fail or never, but
> independent on the input data.
I believe that just because POSIX only documents one specific e
On Mon, Sep 16, 2013 at 12:59:11PM +0100, Peter Rice wrote:
> On 16/09/2013 11:31, Faheem Mitha wrote:
> >This is really not Debian-related, except insofar as the software in
> >question is something that might have been in Debian one day. I talked
> >about that with people on debian-med recently.
Package: wnpp
Severity: wishlist
Owner: Klee Dienes
* Package name: libmini
Version : 10.10~20130925
Upstream Author : Stefan Roettger
* URL : http://stereofx.org/terrain.html
* License : GPL, LGPL, MIT, others
Programming Lang: C, C++, others
Description
Hello!
I intend to drop the iproute transitional packages in Jessie+1.
This message is here to give all 68 packages depending/recommending/suggesting
the old iproute package time to simply update their dependencies to use
the new iproute2 package name.
The fix is simple: sed -ie 's/iproute/iprou
Hi Wookey,
On Wed, Sep 25, 2013 at 7:04 PM, Wookey wrote:
> +++ Sergei Golovan [2013-09-25 12:25 +0400]:
>> Hi fellow developers,
>>
>> I would like to introduce a few significant changes into Debian Tcl/Tk
>> packages.
>
> Thank you for doing this work, and for this clear summary.
>
>> 1. Multia
+++ Sergei Golovan [2013-09-25 12:25 +0400]:
> Hi fellow developers,
>
> I would like to introduce a few significant changes into Debian Tcl/Tk
> packages.
Thank you for doing this work, and for this clear summary.
> 1. Multiarchifying Tcl/Tk. This means splitting out the libtcl8.5
> package wi
Hi,
> This all sounds like a great idea, but I would suggest that rather than
> attempt to be command-line compatible with the existing tool, you
> clearly define a set of command line arguments and their corresponding
> semantics that you *do* support, ensuring that it is an accurate and
> correc
On Mon, Sep 23, 2013 at 04:30:59PM +0200, Dominik George wrote:
> My proposal is to remove unrar-free from Debian, for the reasons
> mentioned above, and add a patch to src:unar that include a wrapper
> script that provides a command-line wrapper compatible to both
> unrar-free and unrar-nonfree, s
Hello,
On 25 September 2013 14:52, Sergei Golovan wrote:
> There are about 30 packages left which unconditionally depend on
> tcl8.4 or tk8.4.
> We have to do some research and find how to port them to 8.5 or 8.6.
When I have some free time, I occasionally port this or that package.
Actually, I'
Hi Matthias,
On Wed, Sep 25, 2013 at 1:39 PM, Matthias Klose wrote:
> Am 25.09.2013 10:25, schrieb Sergei Golovan:
>> Hi fellow developers,
>>
>> I would like to introduce a few significant changes into Debian Tcl/Tk
>> packages. Some of them have quite significant impact on their reverse
>> depe
Hi Cyril,
On Wed, Sep 25, 2013 at 1:38 PM, Cyril Brulebois wrote:
> Hi Sergei,
>
> (replying to the first part only since it strikes me)
>
> Sergei Golovan (2013-09-25):
>> 2. Renaming tcl8.5-dev and tk8.5-dev into libtcl8.5-dev and
>> libtk8.5-dev respectively (the latter packages still provide
On 2013-09-03 13:49, Stefano Zacchiroli wrote:
> On Sun, Aug 25, 2013 at 05:09:22PM +0200, Niels Thykier wrote:
>> How you can help (NEW-TEST-HELP)
>>
>>
>> Add tests to your packages. The full specification for these
>> tests are available from [AUTOPKG]. If yo
Russ Allbery debian.org> writes:
> (consider resource exhaustion errors in the crypt implementation, for
No, the standard said it would either always fail or never, but independent
on the input data.
> Your proposed solution on libc-alpha was ingenious, but I think it breaks
> the crypt contrac
Hello,
On Sep 25, 2013 11:40 AM, "Matthias Klose" wrote:
> Am 25.09.2013 10:25, schrieb Sergei Golovan:
> > removing alternatives a lot. But later I'd like to have another
> > transition (switching to 8.6 as default Tcl/Tk version).
> Do you have numbers what will break with 8.6?
Not many thing
On Wed, Sep 25, 2013 at 5:39 PM, Matthias Klose wrote:
> Am 25.09.2013 10:25, schrieb Sergei Golovan:
>> Hi fellow developers,
>>
>> I would like to introduce a few significant changes into Debian Tcl/Tk
>> packages. Some of them have quite significant impact on their reverse
>> dependencies which
On 2013-09-25 11:38, Cyril Brulebois wrote:
>> > 3. Renaming tcl-dev and tk-dev into libtcl-dev and libtk-dev. Since
>> > too many packages have versioned build-dependencies on tcl-dev or
>> > tk-dev, I chose to retain tcl-dev and tk-dev packages (as
>> > meta-packages which depend on libtcl-dev an
Am 25.09.2013 10:25, schrieb Sergei Golovan:
> Hi fellow developers,
>
> I would like to introduce a few significant changes into Debian Tcl/Tk
> packages. Some of them have quite significant impact on their reverse
> dependencies which will need a transition, I think. The proposed
> changes are a
Hi Sergei,
(replying to the first part only since it strikes me)
Sergei Golovan (2013-09-25):
> 2. Renaming tcl8.5-dev and tk8.5-dev into libtcl8.5-dev and
> libtk8.5-dev respectively (the latter packages still provide the
> former as virtual packages to break as few packages as it could be).
>
Hi,
> Not directly related to this, I noticed that unar depends on
> gnustep-base-runtime, which in turn spawns the gdomap daemon. Is this
> thing needed at all?
I also noticed that. It comes from ${shlibs:Depends} in the package, so
I figure it is indeed needed (the runtime, not the gdomap daemo
Hi fellow developers,
I would like to introduce a few significant changes into Debian Tcl/Tk
packages. Some of them have quite significant impact on their reverse
dependencies which will need a transition, I think. The proposed
changes are already in the experimental branch, so anyone could try
an
On Mon, Sep 23, 2013 at 04:30:59PM +0200, Dominik George wrote:
> I found that the unar command from theunarchiver, which is even
> recommended by the FSF [3], can handle multipart, modern RAR
> archives just fine, only the command-line is incompatible to
> unrar-free and unrar-nonfree [4].
Not d
Howdy,
here is a short update on the progress of the compatibility script.
I have put together a shell script that accepts all command-lines that
unrar-free or unrar-nonfree would accept and correctly parses them into
internal variables. Doing so, I found that:
- Both unrar-free and unrar-nonfr
44 matches
Mail list logo
