On Mon, Mar 09, 2020 at 08:19:52PM +, Melanie Frost wrote:
>
> Debian can be better than this, really
>
Acknowledge. Please show that you understand the meaning of
enough
Regards
Geert Stappers
--
Silence is hard to parse
signature.asc
Description: PGP signature
Package: wnpp
Severity: wishlist
Owner: hacksk
X-Debbugs-CC: debian-devel@lists.debian.org
* Package name : ruby-concord
Version : 0.1.5
Upstream Author : 2012 Markus Schirp
* URL : https://github.com/mbj/concord
* License : Expat
Programming Lang: Ruby
Description : Helper for object composition
Package: wnpp
Severity: wishlist
Owner: Joao Eriberto Mota Filho
* Package name: filetype.py
Version : 1.0.5
Upstream Author : Tomás Aparicio
* URL : https://github.com/h2non/filetype.py
* License : MIT
Programming Lang: Python 3
Description : Small mo
On Sun, 2020-03-08 at 11:44 -0400, Marvin Renich wrote:
> * jnq...@gmail.com [200308 10:58]:
> > On Sat, 2020-03-07 at 21:30 +0100, Tomas Pospisek wrote:
> > > The problem is that installing the package will automatically
> > > start
> > > the
> > > daemon cluster in a "default" configuration.
> >
I've made a first pass at the packaging. If anyone has time to review, it
would be great:
https://github.com/GrokImageCompression/grok/tree/master/debian
Thanks!
On Mon, Mar 9, 2020 at 2:25 PM Aaron Boxer wrote:
>
> On Mon, Mar 9, 2020 at 1:42 PM Andrey Rahmatullin wrote:
>
>> On Mon, Mar 09,
On Mon, 09 Mar 2020 at 20:45:13 +0100, Niels Thykier wrote:
> Simon McVittie:
> > For example, dpkg-buildpackage could perhaps read one glob per
> > line from debian/artifacts and hardlink matched files (if any) into
> > debian/.build/artifacts for collection by a "larger" framework like
> > sbuild
Hello Julian,
On Mon 09 Mar 2020 at 09:43PM +01, Julian Andres Klode wrote:
> On Mon, Mar 09, 2020 at 10:09:46AM +0100, Guillem Jover wrote:
>> We'd like to standardize on a new set of artifact build pathnames
>> for our deb toolchain. [...]
> [...]
>> The use of a hidden directory is to reduce c
On Mon, Mar 09, 2020 at 10:09:46AM +0100, Guillem Jover wrote:
> We'd like to standardize on a new set of artifact build pathnames
> for our deb toolchain. [...]
[...]
> The use of a hidden directory is to reduce clutter and stomping over any
Love the hidden directory.
--
debian developer - deb
‐‐‐ Original Message ‐‐‐
On Monday, March 9, 2020 7:54 PM, Geert Stappers wrote:
> On Mon, Mar 09, 2020 at 07:09:41PM +, Melanie Frost wrote:
>
> > Dear Sam
>
> Dear All,
>
> > From an outsider perspective, this doesn't look like something that
> > belongs in the bug system. I don'
On Mon, Mar 09, 2020 at 07:09:41PM +, Melanie Frost wrote:
> Dear Sam
Dear All,
> From an outsider perspective, this doesn't look like something that
> belongs in the bug system. I don't know your point of view but it
> looks spiteful.
>
> The volunteer was elected as a community representa
Simon McVittie:
Hi :)
> On Mon, 09 Mar 2020 at 10:09:46 +0100, Guillem Jover wrote:
>> We'd like to standardize on a new set of artifact build pathnames
>> for our deb toolchain. These would have the following form:
>>
>> - debian/.build/upstream*
>>
>> These could be used for out-of-tree b
Package: wnpp
Severity: wishlist
Owner: hacksk
X-Debbugs-CC: debian-devel@lists.debian.org
* Package name : ruby-adamantium
Version : 0.2.0
Upstream Author : 2009-2012 Dan Kubb
2012 Markus Schirp (packaging)
* URL : https://github.com/dkubb/adamantium
* License : Expat
Programmi
Dear Sam
>From an outsider perspective, this doesn't look like something that belongs in
>the bug system. I don't know your point of view but it looks spiteful.
The volunteer was elected as a community representative and he's been hounded
ever since. It looks like he asked people to stop thes
On Mon, Mar 9, 2020 at 1:42 PM Andrey Rahmatullin wrote:
> On Mon, Mar 09, 2020 at 12:56:41PM -0400, Aaron Boxer wrote:
> > Thanks, guys. Another question (first time creating a package): is it
> > possible to unpack
> > the openjpeg .deb and re-use the packaging ?
> No, there is no packaging in
On Mon, Mar 09, 2020 at 12:56:41PM -0400, Aaron Boxer wrote:
> Thanks, guys. Another question (first time creating a package): is it
> possible to unpack
> the openjpeg .deb and re-use the packaging ?
No, there is no packaging in the .deb.
Packaging is in the source packages:
https://wiki.debian.o
Package: wnpp
Severity: wishlist
Owner: Daniel Swarbrick
* Package name: golang-gopkg-yaml.v3
Version : 3.0.0
Upstream Author : Canonical Ltd
* URL : https://gopkg.in/yaml.v3
* License : Apache-2.0
Programming Lang: Go
Description : YAML support for the
Thanks, guys. Another question (first time creating a package): is it
possible to unpack
the openjpeg .deb and re-use the packaging ?
On Sun, Mar 8, 2020 at 2:41 PM Andrey Rahmatullin wrote:
> On Sun, Mar 08, 2020 at 02:30:06PM -0400, Aaron Boxer wrote:
> > Hello!
> > I maintain an image compres
Hi,
On Mon, Mar 09, 2020 at 04:02:52PM +0100, Tomas Pospisek wrote:
> In my logic, finding out how "not to start services on install" should
> be documented in `man dpkg` or referenced from that man page. As far as
> I could see there is absolutely no trace of any hint on how to do that
> in that
FWIW:
We have been using debian packaging from a private repository for the last
three years to configure virtual machines.
As a subversion shop, at least, the extraneous files generated by a build
aren't an issue because we simply svn-clean after a build. I believe "git
clean" does the equiva
> On Sun, 8 Mar 2020, Marc Haber wrote:
>
> On Sat, 7 Mar 2020 21:30:33 +0100, Tomas Pospisek
>
> >When I duckduckgo "dpkg do not start service on install" first hit is
> >[1] which contains /absurdly involved/ suggestions to achieve "not
> >starting a daemon upon installation".
> >
> >[1]
>
>http
I'm concerned about a leading . at least for:
* the debian/tmp replacement
* the replacement for the package install directories under debian.
I think that maintaining those directories such that ls shows them will
be more friendly for new maintainers.
So I'd prefer something like debian/build ra
On Mon, 09 Mar 2020 at 10:09:46 +0100, Guillem Jover wrote:
> We'd like to standardize on a new set of artifact build pathnames
> for our deb toolchain. These would have the following form:
>
> - debian/.build/upstream*
>
> These could be used for out-of-tree builds replacing current
>
* jnq...@gmail.com [200308 10:58]:
> On Sat, 2020-03-07 at 21:30 +0100, Tomas Pospisek wrote:
> > The problem is that installing the package will automatically start
> > the
> > daemon cluster in a "default" configuration.
> >
> > [1]
> > https://askubuntu.com/questions/74061/install-packages-wit
Hi!
We currently have many built artifacts being dropped directly under
debian/ or under tool specific directories such as debian/.debhelper/.
These have at least the following problems:
- Make cleaning, an operation that requires executing code from the
source package itself.
- Require k
Hi!
Summary
---
The goal of the following proposal is to standardize a field to split
part of the Essential packages, and add support for it in the package
management stack. There is currently an Important field, that has the
correct semantics but has a very confusing name and is only support
Package: wnpp
Severity: wishlist
Owner: hacksk
X-Debbugs-CC: debian-devel@lists.debian.org
* Package name : ruby-abstract-type
Version : 0.0.7
Upstream Author : 2009-2013 Dan Kubb
2012 Markus Schirp
* URL : https://github.com/dkubb/abstract_type
* License : Expat
Programming Lan
26 matches
Mail list logo
