Bug#865830: Copyright concerns regarding Seafile

a project, we do not have the resources to fully audit all the code we ingest from upstreams and redistribute to our users. We must rely on trust. That depends on the upstream being trustworthy. Ian. -- Ian JacksonThese opinions are my own. If I emailed you from an address @f

Bug#919545: c-graph-2.0.1-1 Debian Release

lp fix it. This will also help a bit because we have a package in preparation which mentions the (new, duplicate) ITP bug in its changelog and we would prefer to avoid another round of changelog-fiddling. Regards, Ian. -- Ian JacksonThese opinions are my own. If I emailed you from an a

Bug#811377: closed by Dmitry Bogatov (Bug#811377: fixed in sysvinit 2.88dsf-60)

id an upload to experimental intending to adopt the package, unaware of our efforts (in part because we failed to write to this RFA bug about them), but that we are welcoming him, or some such. Ian. -- Ian JacksonThese opinions are my own. If I emailed you from an address @fyvzl.net or @eva

Bug#909550: possible conflict over the /usr/bin/ia namespace

Ian Jackson writes ("Re: possible conflict over the /usr/bin/ia namespace"): > Antoine Beaupré writes ("Re: possible conflict over the /usr/bin/ia > namespace"): > > On 2018-09-25 14:22:44, Ian Jackson wrote: > > > If you can't get a better idea I would

Bug#909550: possible conflict over the /usr/bin/ia namespace

Antoine Beaupré writes ("Re: possible conflict over the /usr/bin/ia namespace"): > On 2018-09-25 14:22:44, Ian Jackson wrote: > > If you can't get a better idea I would suggest > > << 0.242+git20151019-1.1~ > > which is all versions until the next draft

Bug#909550: possible conflict over the /usr/bin/ia namespace

Iain Learmonth writes ("Re: possible conflict over the /usr/bin/ia namespace"): > On 25/09/18 14:16, Antoine Beaupré wrote: > > ... but it hasn't been migrated to Salsa. Would you be okay to move this > > in the Python module's team umbrella (as opposed to simply collab-maint)? > > The whole

Bug#909550: possible conflict over the /usr/bin/ia namespace

Antoine Beaupré writes ("Re: possible conflict over the /usr/bin/ia namespace"): > Makes sense. How about: > > Conflicts: python-duckduckgo2 (<= 0.242+git20151019-1) > > This way we assume any newer upload of the package will remove ia? That's not a good choice because it excludes (local)

Bug#909550: possible conflict over the /usr/bin/ia namespace

duckduckgo2 is changed there there should probably be a bug against python-duckduckgo2. I guess that bug doesn't need to be rc ? Ian. -- Ian JacksonThese opinions are my own. If I emailed you from an address @fyvzl.net or @evade.org.uk, that is a private address which bypasses my fierce spamfilter.

Bug#906265: RFH: julia -- ppc64el port of Julia language and LLVM-6.0

nder if `fakechroot' is any use. Ian. -- Ian JacksonThese opinions are my own. If I emailed you from an address @fyvzl.net or @evade.org.uk, that is a private address which bypasses my fierce spamfilter.

Bug#906265: RFH: julia -- ppc64el port of Julia language and LLVM-6.0

Mo Zhou writes ("Bug#906265: RFH: julia -- ppc64el port of Julia language and LLVM-6.0"): > I tried to think of applying for the access to debian's ppc64el porterbox > but it appears to be impossible for a normal user to install the resulting > package and build another package. Although maybe I

Bug#902930: Acknowledgement (ITP: libanyevent-socket-perl -- AnyEvent::Socket implements various utility functions for handling internet protocol addresses and sockets, in an as transparent and simple

Control: close -1 This wnpp bug is nonsense, because this module is already there in the package libanyevent-perl. -- Ian JacksonThese opinions are my own. If I emailed you from an address @fyvzl.net or @evade.org.uk, that is a private address which bypasses my fierce spamfilter.

Bug#902931: ITP: libanyevent-websocket-client-perl -- AnyEvent::WebSocket::Perl is a WebSockets client for Perl AnyEvent

Package: wnpp Severity: wishlist Owner: Ian Jackson * Package name: libanyevent-websocket-client-perl Version : 0.48 Upstream Author : Marc A. Lehmann * URL : https://metacpan.org/pod/AnyEvent::WebSocket::Client * License : Artistic / GPL1+ Programming Lang

Bug#902930: ITP: libanyevent-socket-perl -- AnyEvent::Socket implements various utility functions for handling internet protocol addresses and sockets, in an as transparent and simple way as possible.

Package: wnpp Severity: wishlist Owner: Ian Jackson * Package name: libanyevent-socket-perl Version : 7.14 Upstream Author : Marc A. Lehmann * URL : https://metacpan.org/pod/AnyEvent::Socket * License : Artistic / GPL1+ Programming Lang: Perl Description

Bug#898259: RFP: vscode -- Microsoft Visual Studio Code

Daniel Pocock writes ("Bug#898259: RFP: vscode -- Microsoft Visual Studio Code"): > Package: wnpp > Severity: wishlist > X-Debbugs-CC: debian-de...@lists.debian.org,debian-outre...@lists.debian.org ... > Visual Studio Code regularly comes up in discussions.  Several GSoC > students have asked

Bug#854490: RFP: xva-img -- Citrix XenServer .xva disk extraction tool

Axel Beckert writes ("Bug#854490: RFP: xva-img -- Citrix XenServer .xva disk extraction tool"): > But I might maintain the tool within a team, e.g. under the Debian > Forensics Team. I just don't have very often such files around for > testing as I don't have access to such a server. So maybe

Bug#811377: Bug#851747: sysvinit-utils: unmaintained package should not be Essential

Petter Reinholdtsen writes ("Bug#851747: sysvinit-utils: unmaintained package should not be Essential"): > [Ian Jackson] > > I don't want to do an upload of this package just to change the > > Uploaders - particularly at this stage of the release. > > Why n

Bug#811377: Bug#851747: sysvinit-utils: unmaintained package should not be Essential

Ian Jackson writes ("Bug#851747: sysvinit-utils: unmaintained package should not be Essential"): > Simon McVittie writes ("Bug#851747: sysvinit-utils: unmaintained package > should not be Essential"): > > sysvinit appears to be unmaintained, but it builds an Essen

Bug#792607: spigot != spigot

it. As it is, the best I can do is offer to sponsor somehow who understands these things more than I do. Regards, Ian. -- Ian Jackson <ijack...@chiark.greenend.org.uk> These opinions are my own. If I emailed you from an address @fyvzl.net or @evade.org.uk, that is a private address which bypasses my

Bug#832613: kronatools_2.7+dfsg-1_amd64.changes REJECTED

lar, or "Krona chart" was a medical (or medico-informatical) term before this software existed and it shouldn't have been trademarked (although I doubt anyone wants to fight that). radiant-diagnostic or something maybe ? (I see there is also a Ruby CMS called "radiant".) Ian.

Bug#843021: RFP: yarn -- a fast, reliable, and secure package manager for Node.js

Lars Wirzenius writes ("Re: Bug#843021: RFP: yarn -- a fast, reliable, and secure package manager for Node.js"): > On Thu, Nov 03, 2016 at 02:02:31PM +, Ian Jackson wrote: > > I searched github for `yarn'. > > You don't find my software on github. I do not want to re

Bug#843021: RFP: yarn -- a fast, reliable, and secure package manager for Node.js

Paolo Greppi writes ("Re: Bug#843021: RFP: yarn -- a fast, reliable, and secure package manager for Node.js"): > On 03/11/2016 09:10, Lars Wirzenius wrote: > > My cmdtest package provides yarn, since the main tool it now provides > > is yarn (a testing tool), not cmdtest. Perhaps your package

Bug#830126: IT: purify -- Next-generation radio interferometric imaging

Gijs Molenaar writes ("Bug#830126: IT: purify -- Next-generation radio interferometric imaging"): > Package: wnpp > Owner: Gijs Molenaar > Severity: wishlist > X-Debbugs-Cc: debian-de...@lists.debian.org,debian-as...@lists.debian.org, > debian-pyt...@lists.debian.org > > *

Bug#825809: unclutter alternatives

Axel Beckert writes ("Re: unclutter alternatives"): > So I'm actually very glad that someone else also has interest in > packaging unclutter-xfixes. I'm a user of unclutter. I run it with `-noevents'. I have no idea whether the new approach is going to be a good replacement but I guess it

Bug#765629: RFA: adns -- Asynchronous-capable DNS client library and utilities

Robert Edmonds writes (Bug#765629: RFA: adns -- Asynchronous-capable DNS client library and utilities): Package: wnpp Severity: normal ... I request an adopter for the adns package. The package description is: adns is a resolver library for C (and C++) programs. In contrast with the

Bug#739997: ITA: mumble -- Low latency VoIP client

Chris Knadle writes (ITA: mumble -- Low latency VoIP client): Ron -- I believe the BTS and PTS likely didn't notify you via email, so I wanted to let you know that I filed an ITA [1] on the mumble package yesterday. I'm open to discussing this if your or anyone wishes to. Ah, good, thanks

Bug#739997: ITA: mumble -- Low latency VoIP client

Chris Knadle writes (Bug#739997: ITA: mumble -- Low latency VoIP client): ... This package hasn't been orphaned, but there hasn't been any activity from the maintainer or uploader for ~18 months despite some grave bugs, so I'm offering to adopt the package as the maintainer. I'm familiar with

Bug#733743: ITP: libnih.la -- portable libnih implementation

Dimitri John Ledkov writes (Bug#733743: ITP: libnih.la -- portable libnih implementation): I would like to package a temporary fork of libnih, which has been ported to kFreeBSD/eglibc platform. My plan for this package is to provide same packages as the src:libnih, but for non-Linux ports

Bug#717434: RFA: socat -- multipurpose relay for bidirectional data transfer

Chris Taylor writes (Bug#717434: RFA: socat -- multipurpose relay for bidirectional data transfer): ... I intend to orphan socat in the next few weeks and would like someone to adopt the package as it is still useful to many. I no longer have the time nor motivation/need to continue to

Bug#518696: GNU parallel, name conflict with moreutils

Package: debian-ctte For quite a while we have had a program in moreutils called /usr/bin/parallel. More recently, we have had a new parallel program which has become a GNU project, and which for compatibility would like to own /usr/bin/parallel. The two programs have similar purposes. The GNU

Bug#647255: RFA: curl -- A library and a commandline client for HTTP and a number of protocols

Alessandro Ghedini writes (Re: Bug#647255: RFA: curl -- A library and a commandline client for HTTP and a number of protocols): All the changes are on git [0] (I pushed them yesterday evening). I can build something to upload to mentors.d.n if you prefer. No, that's fine, I'll take a look at

Bug#647255: RFA: curl -- A library and a commandline client for HTTP and a number of protocols

Ramakrishnan Muthukrishnan writes (Bug#647255: RFA: curl -- A library and a commandline client for HTTP and a number of protocols): I am a bit tied up with real life and would like someone to take the maintainance of curl. There is a new upstream version but otherwise the package is in good

Bug#647255: RFA: curl -- A library and a commandline client for HTTP and a number of protocols

Alessandro Ghedini writes (Re: Bug#647255: RFA: curl -- A library and a commandline client for HTTP and a number of protocols): Most of the work was in updating the patches, and I have also cleaned d/control a bit. There is some more work I'd like to do (e.g. fixing all the lintian Info tags

Bug#640954: ITA: unclutter -- hides the cursor in X after a period of inactivity

Axel Beckert writes (Bug#640954: ITA: unclutter -- hides the cursor in X after a period of inactivity): [2] http://git.debian-maintainers.org/?p=daniel/unclutter.git [3] http://anonscm.debian.org/gitweb/?p=collab-maint/unclutter.git Co-maintainers welcome. Thanks for picking this up.

Bug#640954: ITA: unclutter -- hides the cursor in X after a period of inactivity

Axel Beckert writes (Re: Bug#640954: ITA: unclutter -- hides the cursor in X after a period of inactivity): Ian Jackson wrote: I'm willing to help. My alioth id is iwj if you need it. Thanks. Shall I add you to Uploaders? Sure. Regards, Ian. -- To UNSUBSCRIBE, email to debian-wnpp

Bug#614808: O: loop-aes - loop-AES encryption modules

Max Vozeler writes (Bug#614808: O: loop-aes - loop-AES encryption modules): loop-aes has an active and helpful upstream maintainer and quite a few users. Why are these people not using dm-crypt and luks ? Or, why is this code not using dm-crypt rather than an out-of-tree module ? These are

Bug#600777: RFH: cryptsetup -- configures encrypted block devices

Jonas Meurer writes (Bug#600777: RFH: cryptsetup -- configures encrypted block devices): Cryptsetup is the commandline frontend to dm-crypt, the device encryption implemented in the linux kernel. The package contains a lot of scripts and wrappers in order to manage encrypted devices. A key

Bug#426581: meshlab - anyone still working on this

Yaroslav Halchenko writes (Re: Bug#426581: meshlab - anyone still working on this): ok -- upload is sponsored [stuff] Thanks for picking this up while I dropped off the face of the Debian planet for a couple of months. Ian. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of

Bug#426581: meshlab - anyone still working on this

Teemu Ikonen writes (Re: Bug#426581: meshlab - anyone still working on this): The package has not been updated to 1.1.1, and I may not have time to do it very soon. Ian did promise to sponsor the package, but I haven't heard anything from him lately. I do exist but don't let me stop anyone

Bug#426581: meshlab - anyone still working on this

Paolo Cignoni writes (Re: Bug#426581: meshlab - anyone still working on this): So adding a compile option disabling the default home phoning is probably the best idea. That would certainly suffice. At least can I ask for enabling at the first run? Or even this is evil? :) I think that

Bug#426581: meshlab - anyone still working on this

Paolo Cignoni writes (Re: Bug#426581: meshlab - anyone still working on this): We use QT with QSettings mechanism for saving config files in a portable way Can these files be written other than by Qt ? Our configuration management systems often need to write to configuration in situations where

Bug#426581: meshlab - anyone still working on this

Paolo Cignoni writes (Re: Bug#426581: meshlab - anyone still working on this): (shortened and with intermixed answers...) Thanks, that's absolutely the right way to respond. So much so that we don't normally feel the need to mention it :-). On Fri, Feb 22, 2008 at 10:00 PM, Ian Jackson

Bug#426581: meshlab - anyone still working on this

Paolo Cignoni writes (Re: Bug#426581: meshlab - anyone still working on this): Yes, it phones home regularly. It is well written in the docs http://meshlab.sourceforge.net/wiki/index.php/Licenses Thanks for the reference. It seems to me that it is not against the Debian social contract nor

Bug#426581: meshlab - anyone still working on this

Paolo Cignoni writes (Re: Bug#426581: meshlab - anyone still working on this): Ok, I understand your point, I respect and, as i told you since beginning, i agree on disabling it for very pure, and ethically coherent distributions like Debian. As you understood, this data collecting it is

Bug#426581: meshlab - anyone still working on this

Teemu Ikonen writes (Re: Bug#426581: meshlab - anyone still working on this): Thanks for the review. I fixed the problems you found except these: After I built it (on lenny), I ran meshlab from an xterm. It opened an entirely blank override-redirect pale grey window covering the top left

Bug#426581: meshlab - anyone still working on this

Paolo Cignoni writes (Re: Bug#426581: meshlab - anyone still working on this): I am a bit ignorant about debian package creation so be patient with my naiveness :) I would try to help as I can. My comments intermixed below. Thanks for your reply and sorry for the delay in getting back to

Bug#426581: Fwd: Bug#426581: meshlab - anyone still working on this

Teemu Ikonen writes (Fwd: Bug#426581: meshlab - anyone still working on this): Since you asked about meshlab packages a while ago, are you still interested in sponsoring them? I have packages ready for review, see the mail below for details. Thanks. Teemu Ikonen [EMAIL PROTECTED] writes:

Bug#426581: meshlab - anyone still working on this

Teemu Ikonen writes (Re: Bug#426581: meshlab - anyone still working on this): http://esko.osmas.info/~tmx/meshlab/ I've reviewed this and it's looking reasonably good. Firstly, two general observations: * You should run lintian, particularly after making a wholly new package. * With a new

Bug#282283: Splitting dselect from dpkg -- acceptable plan?

Guillem Jover writes (Re: Splitting dselect from dpkg -- acceptable plan?): Hi Nathanael, Is this an acceptable future path for dselect? Is the temporary forking of libdpkg considered acceptable? (One alternative is to make a real, shared libdpkg, but looking at it I don't really think

Bug#282283: Splitting dselect from dpkg -- acceptable plan?

Nathanael Nerode writes (Splitting dselect from dpkg -- acceptable plan?): My plan for dselect is to make dselect more fully based on apt, [...] Is this an acceptable future path for dselect? No. insert rant about apt I still use dselect on all of my Debian systems and I don't want to switch

Bug#414844: copyright notices and clarity

Rafael writes: Look, for instance, at the text of the GPL, around this excerpt: How to Apply These Terms to Your New Programs [snip] To do so, attach the following notices to the program. It is safest to attach them to the start of each source file to most effectively

Bug#390754: O: piuparts -- .deb package installation, upgrading, and removal testing tool

John Wright writes (Re: Bug#390754: O: piuparts -- .deb package installation, upgrading, and removal testing tool): I would be interested in co-maintaining this package. I don't think I have the time to give it the full attention it would need (e.g. filing bugs on packages that fail), but I