As 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 @fyvzl.n
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
mentioning that he did 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 addres
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
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
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 salsa
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) backpo
ckgo2 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.
I wonder 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.
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 c
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.
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
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
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 abou
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 some
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 not?
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
me `radiant-graphs'. If that is
rejected by ftpmaster you should involve the DPL and/or the TC.
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.
nsider
packaging 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 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.
nd XML files.
Either this is circular, 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 call
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
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 coul
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
>
> * Package name: puri
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 probab
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 th
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
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,
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
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 mai
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 GN
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
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 t
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 goo
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
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 u
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 a
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
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
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
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
whe
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
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
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 contra
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, 200
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
>
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 t
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 n
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
Is anyone still working on the meshlab package (and the vcg library) ?
I have a use for it and hoped to find a package, or failing that I
might try to put one together myself.
How far has anyone got ? Any information or pointers would be
valuable.
I found this:
http://gnu.ethz.ch/debian/meshl
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
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.
I still use dselect on all of my Debian systems and I don't want to
switch to using apt. dse
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 effectiv
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), bu
53 matches
Mail list logo
