On February 14, 2020 7:45:30 PM UTC, Alan Corey wrote:
>What if we define an epoch to be 50 years and the epoch number becomes
>part of how the computer keeps track of the date. Something similar
>is done in astronomy I think, star charts always have an epoch. So
>epoch 0 was 1970, epoch 1 is
On 2/14/20 4:46 PM, Dimitri John Ledkov wrote:
> Can a Debian Package Maintainer require CLA for accepting packaging
> changes and distro patches to be uploaded into Debian itself?
you can always fork the current packaging and upload/NMU it.
Send patches to the BTS or open an issue in github, poin
In this instance, I'd submit a patch to the bts and see what happens.
--Sam
Package: wnpp
Owner: Hilko Bengen
Severity: wishlist
* Package name: paraglob
Version : 0.4
Upstream Author : Corelight Inc.
* URL or Web page : https://github.com/zeek/paraglob
* License : BSD-3-clause, LGPL-3+
Description : library for matching strings against a la
* Andrey Rahmatullin:
> On Fri, Feb 14, 2020 at 06:38:00PM +0100, Florian Weimer wrote:
>> It would also make the package unmaintainable if the
>> original packer loses interest, so the package would not be suitable
>> for inclusion in a stable release.
> Can you explain why do you think so?
> If
What if we define an epoch to be 50 years and the epoch number becomes
part of how the computer keeps track of the date. Something similar
is done in astronomy I think, star charts always have an epoch. So
epoch 0 was 1970, epoch 1 is 2000, epoch 2 is 2050. Then we can keep
a time_t at 32 bits.
On Fri, Feb 14, 2020 at 06:38:00PM +0100, Florian Weimer wrote:
> It would also make the package unmaintainable if the
> original packer loses interest, so the package would not be suitable
> for inclusion in a stable release.
Can you explain why do you think so?
If a new maintainer wants to use a
* Scott Kitterman:
> On February 14, 2020 3:46:18 PM UTC, Dimitri John Ledkov
> wrote:
>>Can a Debian Package Maintainer require CLA for accepting packaging
>>changes and distro patches to be uploaded into Debian itself?
>>
>>(case in point, debian maintainer & upstream wear the same hat, and
>>
On Tue, Feb 04 2020, Steve McIntyre wrote:
> Arnd scanned the library packages in the Debian archive and identified
> that about one third of our library packages would need rebuilding
> (and tracking) to make a (recursive) transition. We can see two
> different possible routes to follow:
>
> A F
On February 14, 2020 3:46:18 PM UTC, Dimitri John Ledkov
wrote:
>Can a Debian Package Maintainer require CLA for accepting packaging
>changes and distro patches to be uploaded into Debian itself?
>
>(case in point, debian maintainer & upstream wear the same hat, and
>maintain upstream code & p
On Fri, Feb 14, 2020 at 03:46:18PM +, Dimitri John Ledkov wrote:
> Can a Debian Package Maintainer require CLA for accepting packaging
> changes and distro patches to be uploaded into Debian itself?
>
> (case in point, debian maintainer & upstream wear the same hat, and
> maintain upstream cod
Can a Debian Package Maintainer require CLA for accepting packaging
changes and distro patches to be uploaded into Debian itself?
(case in point, debian maintainer & upstream wear the same hat, and
maintain upstream code & packaging on github.com, under a company org
with a CLA bot, rejecting debi
On Wednesday, 5 February 2020 22:40:29 CET Dmitry Smirnov wrote:
> There are log readers like "lnav" and "multitail" that will become useless
> without traditional log files. "lnav" tails multiple logs by default and
> IMHO provides a very useful interface.
multitail provides -l option to read log
Package: wnpp
Severity: wishlist
Owner: Mo Zhou
* Package name: smartdns
* URL : https://github.com/pymumu/smartdns/releases
* License : GPL-3+
Programming Lang: C
Description : local DNS server to obtain the fastest IP for the best
experience
The package is alr
14 matches
Mail list logo
