Package: wnpp
Severity: wishlist
Owner: Andrew Ayer
* Package name: git-crypt
Version : 0.4.2
Upstream Author : Andrew Ayer
* URL : https://www.agwa.name/projects/git-crypt
* License : GPL3+ with OpenSSL linking exception
Programming Lang: C++
Description
The following is a listing of packages for which help has been requested
through the WNPP (Work-Needing and Prospective Packages) system in the
last week.
Total number of orphaned packages: 661 (new: 1)
Total number of packages offered up for adoption: 170 (new: 1)
Total number of packages request
Arnaud Fontaine (2015-05-14):
> I tried to use http.debian.net instead of my local mirror, namely
> http://ftp.jp.debian.org, last year and it was redirecting me to much
> mirrors not in Japan (Taiwan or Korea). I sent 2 emails to you about
> that but never got any reply so not sure
Hi Norbert,
Norbert Preining (2015-05-14):
> Hi everyone
>
> (please Cc)
>
> I recently switched from a pre-release of the installer images
> .../sid_d-i/current/amd64/iso-cd/firmware-testing-amd64-netinst.iso
> (taken sometime about a year ago, or so)
>
> to the final version
> ... firmware-
❦ 4 avril 2015 10:54 +0200, Niels Thykier :
> * There is an experimental branch for debhelper to generate these
>automatically available.
>- Requires a "export DH_BUILD_DDEBS=1" to trigger the code path
>- It applies to *all* compat levels.
>- Trying to get the reproducible tea
❦ 14 mai 2015 17:22 +0300, Исаев Виталий :
> Regarding the state of containers after the finish of the build
> process: we surely don't need them anymore. Every container is used
> just once and removed after a while. We have docker image with
> preinstalled compilers and packaging toolchain. Al
❦ 14 mai 2015 14:57 +0100, Neil Williams :
>> More seriously, but this needs some additional work, it should be
>> easier to manage persistent build dependencies. The first time you
>> build a package, it retrieves and install all deps. The second time,
>> the build environment is already here.
Package: wnpp
Severity: wishlist
Owner: Dmitry Bogatov
* Package name: cdist
Version : 4.0.0pre3
Upstream Author : Nico Schottelius
* URL : http://www.nico.schottelius.org/software/cdist/
* License : GPLv3+
Programming Lang: Python, Shell
Description
Package: wnpp
Severity: wishlist
Owner: Balasankar C
* Package name: rexical
Version : 1.0.5
Upstream Author : ARIMA Yasuhiro
* URL : https://github.com/tenderlove/rexical
* License : LGPL-2.1
Programming Lang: Ruby
Description : Lexical scanner genera
Le mercredi 13 mai 2015 à 19:14 +0300, Исаев Виталий a écrit :
> Hello! I'm looking for a convenient wrapper of standard Debian
> packaging toolchain in order to automatize the deployment process. We
> use Ubuntu and Debian, and the most part of code is written in C++,
> therefore we need to compil
Package: wnpp
Severity: wishlist
Owner: Colin Tuckley
* Package name: tucnak
Version : 4.03
Upstream Author : Ladislav Vaiz
* URL : http://tucnak.nagano.cz
* License : GPL-2
Programming Lang: C
Description : VHF/UHF/SHF Hamradio contest logging program
Hello Tzafrir, thanks for pointing the mini-buildd. I've never heared
about this tool. Will try to grab more info about it.
Sincerely,
Vitaly Isaev
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Ar
Hi, Neil, thanks for a prompt reply.
I need to clarify our use case indeed. Some of our projects contain both
free and proprietary code. So the "Privacy" feature I mentioned in the
initial message means that packages built from these projects
(currently) is only for internal use. We have priva
Regarding the state of containers after the finish of the build process:
we surely don't need them anymore. Every container is used just once and
removed after a while. We have docker image with preinstalled compilers
and packaging toolchain. All the dependencies are being installed every
time
On Thu, 14 May 2015 15:45:01 +0200
Vincent Bernat wrote:
> ❦ 14 mai 2015 14:02 +0100, Neil Williams :
>
> >> 1. Gitlab;
> >> 2. Isolated build environment inside Docker containers (where we
> >> usually do `git clone && mk-build-deps && debuild`);
> >> 3. Aptly;
> >> 4. Self-written Py
Package: wnpp
Severity: wishlist
Owner: Antonio Terceiro
* Package name: chake
Version : 0.6
Upstream Author : Antonio Terceiro
* URL : https://gitlab.com/terceiro/chake
* License : MIT (Expat)
Programming Lang: Ruby
Description : serverless configurat
❦ 14 mai 2015 14:02 +0100, Neil Williams :
>> 1. Gitlab;
>> 2. Isolated build environment inside Docker containers (where we
>> usually do `git clone && mk-build-deps && debuild`);
>> 3. Aptly;
>> 4. Self-written Python scripts linking all these components;
>
> What is the reason for doc
On Wed, 13 May 2015 19:14:36 +0300
Исаев Виталий wrote:
> Hello! I'm looking for a convenient wrapper of standard Debian
> packaging toolchain in order to automatize the deployment process.
It would seem to be attainable, but then each use case goes off on a
particular tangent:
> We
> use Ubunt
Hi Lisandro,
> I have just checked qt5's multimedia. The GStreamer 1.0 support will most
> probably be part of Qt 5.5.0, due to June/July.
>
> Worst case scenario: if you decide to go ahead with the removal before we can
> get 5.5.0 into the archive then I can simply disable gstreamer support o
On Wed, May 13, 2015 at 07:14:36PM +0300, Исаев Виталий wrote:
> Hello! I'm looking for a convenient wrapper of standard Debian packaging
> toolchain in order to automatize the deployment process. We use Ubuntu and
> Debian, and the most part of code is written in C++, therefore we need to
> compil
On 2015-05-02 13:46, David Kalnischkies wrote:
> On Fri, May 01, 2015 at 11:46:42PM +0200, Niels Thykier wrote:
>> […] ddeb support […]
>
> +1. \o/
>
>
>>- apt now properly handles the "pkg:arch" dependency.
>
> [...]
>
> I would revert the revert as this is potentially causing more troubl
On 2015-04-19 19:10, David Kalnischkies wrote:
> On Sat, Apr 04, 2015 at 10:54:09AM +0200, Niels Thykier wrote:
>> The resulting debs are installable with dpkg -i ( \o/ ). I have not
>> tried anything fancy like setting up a local APT mirror and tried to
>> convince APT do install it.
>
> I did a
On 2015-04-12 05:31, Paul Wise wrote:
> On Sat, Apr 11, 2015 at 3:20 PM, Niels Thykier wrote:
>
>> As noted on IRC, mentors.debian.net / debexpo will probably need to be
>> updated too (at least if we go the "ddebs" route).
>
> debexpo needs a rewrite to a non-deprecated framework so support for
On 2015-05-03 18:58, Guillem Jover wrote:
> Hi!
>
> On Tue, 2015-04-07 at 22:11:18 +0200, Niels Thykier wrote:
>> A) Use ".deb" (i.e. the regular extension) with a new "section".
>
> Is there any problem with using the existing "debug" section? Or is
> the different section used to distinguish
On May 13, "D. Jared Dominguez" wrote:
> >- it does not seem to me to provide any benefit over the firmware-based
> > names since in practice both would use by default an interface index
> > in the common case
> Firmware based in what sense? From the biosdevname readme, biosdevname uses:
> PCI Co
On Thu, 14 May 2015 09:07:16 +1000, Russell Stuart
wrote:
>On Wed, 2015-05-13 at 17:16 +0200, Vincent Lefevre wrote:
>> Well, having some of the network traffic (more precisely, connections
>> to machines that have an IPv6 address) re-routed to some unknown
>> machine on the local network is not a
26 matches
Mail list logo
