Hi
SZ Lin (林上智) 於 2020年3月5日 週四 下午6:39寫道：
>
> Hi Scott,
>
> Scott Kitterman 於 2020年3月1日 週日 下午1:28寫道：
> >
> > On Sunday, March 1, 2020 12:06:13 AM EST SZ Lin (林上智) wrote:
> > > Hi all,
> > >
> > > I'm working on fixing bugs (including RC) on google-authenticator[1] which
> > > name should be "goog
--
SZ Lin (林上智) , http://people.debian.org/~szlin
Debian Developer, debian.org.tw Administrator
4096R/ 178F 8338 B314 01E3 04FC 44BA A959 B38A 9561 F3F9
SZ Lin (林上智) 於 2020年3月5日 週四 下午6:39寫道：
>
> Hi Scott,
>
> Scott Kitterman 於 2020年3月1日 週日 下午1:28寫道：
> >
> > On Sunday, March 1, 2020 12:06:13
On Mar 10, Marvin Renich wrote:
> > The modern and simple solution is "systemctl mask", as long as you do
> > not need to care about the 0.6% of systems which do not use systemd.
> > If you are doing this for your own systems then you obviously know if
> > you can rely on systemd or not.
> I do
Package: wnpp
Severity: wishlist
Owner: Juhani Numminen
* Package name: python-pysol-cards
Version : 0.8.8
Upstream Author : Shlomi Fish
* URL : https://github.com/shlomif/pysol_cards
* License : Expat
Programming Lang: Python
Description : Deal PySol
Marvin Renich writes:
> * Marco d'Itri [200310 11:23]:
>> The modern and simple solution is "systemctl mask", as long as you do
>> not need to care about the 0.6% of systems which do not use systemd.
>> If you are doing this for your own systems then you obviously know if
>> you can rely on syst
Marvin Renich writes:
> I don't believe this is correct, though I could be wrong. I believe
> policy-rc.d is sufficient for both systemd and sysvinit systems, and
> that it is necessary for _packages_ that only ship an init script and
> not a service file, regardless of the init system in use.
* Marco d'Itri [200310 11:23]:
> The modern and simple solution is "systemctl mask", as long as you do
> not need to care about the 0.6% of systems which do not use systemd.
> If you are doing this for your own systems then you obviously know if
> you can rely on systemd or not.
I don't believe
On Tue, Mar 10, 2020 at 8:46 AM Sudip Mukherjee
wrote:
> On Tue, Mar 10, 2020 at 12:29 PM Aaron Boxer wrote:
> >
> > Thanks, Sudip! I've made those changes, and renamed the library to
> grok-jpeg2000
> >
> > The only thing missing right now is the copyright file. Is there a way
> of automaticall
On Tue, 2020-03-10 at 18:48 +0100, Simon Richter wrote:
> Hi,
>
> On Tue, Mar 10, 2020 at 03:50:42PM +, jnq...@gmail.com wrote:
>
> > - the 'move start-stop-daemon' trick is the old-old solution, kept
> > around because some packages failed to get on board with the
> > policy-
> > rc.d solut
Hi,
On Tue, Mar 10, 2020 at 03:50:42PM +, jnq...@gmail.com wrote:
> - the 'move start-stop-daemon' trick is the old-old solution, kept
> around because some packages failed to get on board with the policy-
> rc.d solution, and could be removed from things like debootstrap/live-
> build if an
Package: wnpp
Severity: wishlist
Owner: Mario Limonciello
* Package name: libjcat
Version : 0.1.0
Upstream Author : Richard Hughes
* URL : https://github.com/hughsie/libjcat
* License : LGPL 2.1+
Programming Lang: C
Description : JSON Catalog library
On Tue, 2020-03-10 at 16:23 +0100, Marco d'Itri wrote:
> On Mar 10, jnq...@gmail.com wrote:
>
> > If the policy-rc.d solution is the modern/best/whatever solution,
> > the
> No. policy-rc.d is the old solution which was implemented because
> there
> was no better way to implement this with init s
On Mar 10, jnq...@gmail.com wrote:
> If the policy-rc.d solution is the modern/best/whatever solution, the
No. policy-rc.d is the old solution which was implemented because there
was no better way to implement this with init scripts.
It worked by mandating that maintainer scripts must start and s
On Tue, 2020-03-10 at 19:39 +0500, Andrey Rahmatullin wrote:
> On Tue, Mar 10, 2020 at 02:33:50PM +, jnq...@gmail.com wrote:
> > If the policy-rc.d solution is the modern/best/whatever solution,
> > the
> > fact that live-build/debootstrap also includes the 'moving start-
> > stop-
> > daemon'
On Tue, Mar 10, 2020 at 02:33:50PM +, jnq...@gmail.com wrote:
> If the policy-rc.d solution is the modern/best/whatever solution, the
> fact that live-build/debootstrap also includes the 'moving start-stop-
> daemon' trick is either indeed a left over from before systemd (I do
> not know the hi
On Tue, 2020-03-10 at 08:47 -0400, Marvin Renich wrote:
> I think the OP's question was not about creating a package with a
> daemon
> that is disabled by default, but about preventing an existing
> package,
> that would otherwise start its daemon, from starting it.
That was my understanding also.
* David Bremner:
> Julian Andres Klode writes:
>
>>
>> apt install _toremove +toinstall
>>
>
> A common convention is to do something like
>
> apt install -- -toremove +toinstall
>
> I would prefer that to rolling our own syntax, unless there's some good
> reason (other than the small amount of e
Julian Andres Klode writes:
>
> apt install _toremove +toinstall
>
A common convention is to do something like
apt install -- -toremove +toinstall
I would prefer that to rolling our own syntax, unless there's some good
reason (other than the small amount of extra typing)
d
* Simon Richter [200309 12:33]:
> 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 a
On Tue, Mar 10, 2020 at 12:29 PM Aaron Boxer wrote:
>
> Thanks, Sudip! I've made those changes, and renamed the library to
> grok-jpeg2000
>
> The only thing missing right now is the copyright file. Is there a way of
> automatically parsing all
> .cpp/.h files in the project and generating a lis
On Tue, Mar 10, 2020 at 08:36:25AM -0400, The Wanderer wrote:
> On 2020-03-10 at 06:58, Julian Andres Klode wrote:
>
> > On Sat, Mar 07, 2020 at 09:41:44PM +0100, Julian Andres Klode wrote:
> >
> >> ### Incompatibilities
> >>
> >> * The apt(8) command no longer accepts regular expressions or wild
On 2020-03-10 at 06:58, Julian Andres Klode wrote:
> On Sat, Mar 07, 2020 at 09:41:44PM +0100, Julian Andres Klode wrote:
>
>> ### Incompatibilities
>>
>> * The apt(8) command no longer accepts regular expressions or wildcards as
>> package arguments, use patterns (see New Features).
>
> Corre
Thanks, Sudip! I've made those changes, and renamed the library to
grok-jpeg2000
The only thing missing right now is the copyright file. Is there a way of
automatically parsing all
.cpp/.h files in the project and generating a list of the copyrights ?
On Tue, Mar 10, 2020 at 6:26 AM Sudip Mukherj
Guillem Jover wrote:
> 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 conf
On Sat, Mar 07, 2020 at 09:41:44PM +0100, Julian Andres Klode wrote:
> ### Incompatibilities
>
> * The apt(8) command no longer accepts regular expressions or wildcards as
> package arguments, use patterns (see New Features).
Correction - regular expressions starting in ^ or ending in $ (that i
On Mon, Mar 9, 2020 at 11:52 PM Aaron Boxer wrote:
>
> 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
Just few things from a quick look.
1. compat level is too old, current one is 12
On Tue, 10 Mar 2020 at 07:19:59 +, Paul Wise wrote:
> On Tue, Mar 10, 2020 at 7:12 AM Niels Thykier wrote:
> > Standardized way of extracting additional build-time artefacts
>
> This reminds me of the BYHAND stuff, I forget how that works though.
I think how that works is that at the appropri
On Tue, 10 Mar 2020 at 08:10:55 +0100, Niels Thykier wrote:
> Just to clarify something related. Should debhelper and other tools by
> default archive "certain files of possible interest" (e.g. config.log)?
> Or should we limit it to "on request only"?
I think it would probably make most sense fo
On Tue, Mar 10, 2020 at 7:12 AM Niels Thykier wrote:
>
Standardized way of extracting additional build-time artefacts
This reminds me of the BYHAND stuff, I forget how that works though.
--
bye,
pabs
https://wiki.debian.org/PaulWise
Simon McVittie:
> 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" framew
30 matches
Mail list logo
