Package: wnpp
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org,
pkg-rust-maintain...@lists.alioth.debian.org
Package name: boringtun
Version: 0.2.0
Upstream Author: Cloudflare, Inc.
License: BSD-3-Clause
URL: https://github.com/cloudflare/boringtun
❦ 6 février 2020 09:50 +11, Dmitry Smirnov :
>> and 2) continuing to use rsyslog isn't an option if the default changes.
>
> No. I just don't want default to change. IMHO rationale for this is weak but
> everybody keeps arguing that it would not be a big deal. In time we will see
> how that go
From where I stand it seems to me that you actually don’t care about free
software or DFSG or Debian and you only care about enforcing your worldview
upon others. You need to stop, go read DFSG and come back only if you and come
back with valid arguments how the DFSG is being violated. Or just s
And yet you *demand* in a very aggressive way that others dedicate their
capacity on your misinterpretation of DFSG. Just stop.
Thanks,
--
Ondřej Surý
> On 6 Feb 2020, at 00:27, Dmitry Smirnov wrote:
>
> I would have done so if I had enough capacity.
I think you should stop here and now. You are misinterpreting DFSG to make a
point. And instead of asking how you can help you just throw accusations. In
both you recent threads. We are all in this together and your style is not
helpful just hurtful.
Ondrej
--
Ondřej Surý
> On 6 Feb 2020, at
Spiritually I really would like to see a transparent workflow of the FTP
team. If it were a couple years ago I may stand in the same position as
you. But now I'd kindly invite you to review the FTP team workflow (I
joined the FTP team in order to review it), review the functionalities
of dak (at le
On February 5, 2020 8:44:43 PM UTC, Dmitry Smirnov wrote:
>On Wednesday, 5 February 2020 11:01:08 AM AEDT Scott Kitterman wrote:
>> We just had a GR where the project voted it was just fine to systemd
>all
>> the things, so this sort of thing is to be expected.
>
>Are you suggesting that voters
On February 5, 2020 8:43:43 AM UTC, Bastian Blank wrote:
>Hi Scott
>
>On Wed, Feb 05, 2020 at 07:44:25AM +, Scott Kitterman wrote:
>> >> Of course the fact that I can't use all the tools available to
>> >manipulate text
>> >> files to follow or analyze logs is problematic. If I'm using
>>
Hi Mo,
thanks for your interest in our projects.
> As you know, I cannot help to care about every topic about Debian + AI.
:-D You are doing already an incredible amount.
> For good wish, could you please make a list of packages involved in
> these projects, so I can inspect them and make sure
On 2/5/20 7:36 PM, Paul Wise wrote:
> AFAICT from Debian's FHS
> documentation, since /srv is laid out differently on different hosts
> packages should not rely on a particular layout. My interpretation is
> of this is that packages should never touch /srv unless directed to do
> so by the sysadmin
On Thu, Feb 06, 2020 at 09:50:36AM +1100, Dmitry Smirnov wrote:
On Thursday, 6 February 2020 9:04:33 AM AEDT Michael Stone wrote:
Nobody said "exclusively" except you!
It was suggested that default will change and I'm concerned about that.
And yet you said "exclusively" and generally argued
This is not a disagreement with anything you write.
I've noticed that there is a lot more configuration that gets encoded in
the initramfs than I thought.
The most surprising for me is that if you want to control the names of
network devices or anything else set by the .link file,
that ends up nee
Hi all,
In [1] there are several packages that reference /srv in their
maintainer scripts or debconf prompts. AFAICT from Debian's FHS
documentation, since /srv is laid out differently on different hosts
packages should not rely on a particular layout. My interpretation is
of this is that packages
Dmitry Smirnov writes:
> On Thursday, 6 February 2020 10:22:24 AM AEDT Russ Allbery wrote:
>> I can't speak for Bernd, but I haven't seen any evidence in this thread
>> that the built binary is not DFSG-compliant.
> So now you are going to nitpick on my language with all your eloquence? :(
Accu
Please! Not now!
I absolutely think that accountability and transparency for a couple of
delegated teams --and really for delegations in general--needs to be one
of the big issues for the next DPL. I think that's true whether it is
me or someone else.
Our delegates put a lot of time and energy i
Hello,
I think your dispute goes down to the question if Debian's community
infrastructure should preferably using software packaged for Debian
(which salsa is doing) with the binaries Debian offers (which salsa is
not doing). I find this interesting. The two positions are
A) No idea why this sh
On Thursday, 6 February 2020 10:22:24 AM AEDT Russ Allbery wrote:
> I can't speak for Bernd, but I haven't seen any evidence in this thread
> that the built binary is not DFSG-compliant.
So now you are going to nitpick on my language with all your eloquence? :(
The first problem is that packaged
IMHO it is disturbing that one of the most essential processes in Debian
-- acceptance of new and modified packages -- operates almost in secrecy.
Unlike most Debian teams, ftp-masters communicate in private mail list.
I understand why security team might need to operate without full public
disclo
El 5/2/20 a las 21:25, Dmitry Smirnov escribió:
> On Tuesday, 26 February 2019 1:19:35 AM AEDT Inaki Malerba wrote:
>> [0] https://salsa.debian.org/salsa-ci-team/pipeline/blob/master/README.md
>
> Thank you for providing this useful service.
>
> My big concern though is that primary gitlab-runner
On 2/6/20 12:13 AM, Dmitry Smirnov wrote:
> On Thursday, 6 February 2020 9:52:47 AM AEDT Bernd Zeimetz wrote:
>
>> Really don't care.
>
> I see that... :(
See, I prefer to spend my time on doing open source software. I use
tools I can use and that are provided by others, even if the build was
Dmitry Smirnov writes:
> Sources are somewhere, true. But build (binary) is not DFSG-compliant.
> I feel like you are making your point by pretending not to understand...
> Why all this denial?
I can't speak for Bernd, but I haven't seen any evidence in this thread
that the built binary is not
On 2/5/20 5:05 PM, Dmitry Smirnov wrote:
> It should be on abuser
Saying "abuser" is inflammatory, especially as no abuse has been proven.
Please stop.
> to explain that it was not possible to build a
> service in a fully DFSG compliant manner
Why is the current solution not DFSG compliant?
>
On Thursday, 6 February 2020 9:52:47 AM AEDT Bernd Zeimetz wrote:
> Really don't care.
I see that... :(
> You are free to setup and run your own runner.
Just because you did not setup yours properly?
I do maintain my own runner but it is not for everybody due to capacity
constrains.
But let
On Wed, 2020-02-05 at 22:42 +, Sudip Mukherjee wrote:
> On Wed, Feb 5, 2020 at 10:22 PM Christian Barcenas
> wrote:
> > Because this changes the versioning scheme from kernel releases
> > (libbpf-dev and libbpf0 currently are at 5.4.13-1 in sid) to libbpf
> > version numbers (0.0.6-1), the epo
On Thursday, 6 February 2020 9:53:09 AM AEDT Dmitry Smirnov wrote:
> On Thursday, 6 February 2020 9:25:29 AM AEDT intrigeri wrote:
> > I'd love if you would use wording less morally/emotionally loaded than
> > "excuse" here: for me at least, "excuse" is bound to the thought
> > framework of guilt,
On 2/5/20 11:52 PM, Bernd Zeimetz wrote:
> You are free to setup and run your own runner.
> Its even possible to share them for everybody.
> If you do, I'd suggest you add some appropriate tags so people can force
> their builds to run on a runner built from Debian source.
> (there is not irony
On Thursday, 6 February 2020 9:04:33 AM AEDT Michael Stone wrote:
> Nobody said "exclusively" except you!
It was suggested that default will change and I'm concerned about that.
> Either option has benefits and
> disadvantages, but for some reason you're arguing as though 1) only your
> particul
On Thursday, 6 February 2020 9:25:29 AM AEDT intrigeri wrote:
> I'd love if you would use wording less morally/emotionally loaded than
> "excuse" here: for me at least, "excuse" is bound to the thought
> framework of guilt, accusation, and absolute right vs. absolute wrong.
> Framing the discussion
On 2/5/20 11:42 PM, Dmitry Smirnov wrote:
> Sources are somewhere, true. But build (binary) is not DFSG-compliant.
Why? Because it was not built in Debian?
> Don't you think it would be _better_ to use (only) components from "main"?
> Certainly there will be more integrity if you can do that.
Andrey Rahmatullin - 05.02.20, 22:17:14 CET:
> On Thu, Feb 06, 2020 at 07:44:43AM +1100, Dmitry Smirnov wrote:
> > > We just had a GR where the project voted it was just fine to
> > > systemd all the things, so this sort of thing is to be expected.
> >
> > Are you suggesting that voters fully unde
On Wed, Feb 5, 2020 at 10:22 PM Christian Barcenas
wrote:
>
> Because this changes the versioning scheme from kernel releases
> (libbpf-dev and libbpf0 currently are at 5.4.13-1 in sid) to libbpf
> version numbers (0.0.6-1), the epoch needs to be incremented to 1 I
> believe.
I had this doubt but
On Thursday, 6 February 2020 9:11:07 AM AEDT Bernd Zeimetz wrote:
> They are not shipped in Debian, but they are free software,
> binaries with sources being available, as far as I can see all under a
> dfsg free license.
Sources are somewhere, true. But build (binary) is not DFSG-compliant.
I fe
Because this changes the versioning scheme from kernel releases
(libbpf-dev and libbpf0 currently are at 5.4.13-1 in sid) to libbpf
version numbers (0.0.6-1), the epoch needs to be incremented to 1 I
believe.
CC'ing debian-devel for discussion/consensus, per Debian Policy Manual 5.6.12.
Christian
Hi,
Dmitry Smirnov (2020-02-06):
> Now when we have a proper package for a while what excuse do you
> have to continue to use vendor binaries that could not be accepted
> to Debian?
I'd love if you would use wording less morally/emotionally loaded than
"excuse" here: for me at least, "excuse" is
On Thu, Feb 06, 2020 at 08:40:29AM +1100, Dmitry Smirnov wrote:
On Thursday, 6 February 2020 6:59:38 AM AEDT Nikolaus Rath wrote:
I would venture that for every user who is grateful that
/var/log/mail.log collects all the various mail-related logs, there is
another user that curses about non bei
Dmitry Smirnov writes:
> 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.
> Exclusively relying on systemd logging facilities limits ways in which
> we ca
On 2/5/20 10:33 PM, Dmitry Smirnov wrote:
> Upstream binaries are not DFSG compliant.
Why?
> Not only they use shitload of
> vendored libraries
That is how go works. The exact version is available, the source code also.
The way how the docker image is being built is actually in the sources,
On 2/5/20 2:52 PM, Nikolaus Rath wrote:
I think it's worth pointing out that this was an experimental feature
that users explicitly had to opt into. The original statement feels
misleading to me.
That's how it started, further looking (sorry, was replying from my
phone before) give things li
On Thursday, 6 February 2020 6:59:38 AM AEDT Nikolaus Rath wrote:
> I would venture that for every user who is grateful that
> /var/log/mail.log collects all the various mail-related logs, there is
> another user that curses about non being able to separate (out of the
> box) the logs from all the
Le mercredi, 5 février 2020, 21.44:43 h CET Dmitry Smirnov a écrit :
> On Wednesday, 5 February 2020 11:01:08 AM AEDT Scott Kitterman wrote:
> > We just had a GR where the project voted it was just fine to systemd all
> > the things, so this sort of thing is to be expected.
>
> Are you suggesting
On Thursday, 6 February 2020 8:10:17 AM AEDT Bernd Zeimetz wrote:
> You are free not to use salsa or not to use the gitlab runners.
> You are also free to rewrite the gitlab runner in a free version, if I
> remember right the api is published, so this should not be hard.
What warrants such a hosti
On Wed, Feb 5, 2020 at 3:03 PM Dmitry Smirnov wrote:
>
> Anyway the big disadvantage of changing default is that now random Debian
> systems will have no traditional logging interface (rsyslog) and we're all
> will be forced to adapt to the new interface in the absence of old one on
> some system
On Thu, Feb 06, 2020 at 07:44:43AM +1100, Dmitry Smirnov wrote:
> > We just had a GR where the project voted it was just fine to systemd all
> > the things, so this sort of thing is to be expected.
>
> Are you suggesting that voters fully understood the implications?
> Is this OK now to replace ev
On 2/5/20 9:25 PM, Dmitry Smirnov wrote:
> On Tuesday, 26 February 2019 1:19:35 AM AEDT Inaki Malerba wrote:
>> [0] https://salsa.debian.org/salsa-ci-team/pipeline/blob/master/README.md
>
> Thank you for providing this useful service.
>
> My big concern though is that primary gitlab-runner 12.
On Wednesday, 5 February 2020 11:01:08 AM AEDT Scott Kitterman wrote:
> We just had a GR where the project voted it was just fine to systemd all
> the things, so this sort of thing is to be expected.
Are you suggesting that voters fully understood the implications?
Is this OK now to replace everyt
On Feb 05 2020, Scott Kitterman wrote:
> On February 5, 2020 12:35:45 PM UTC, Ansgar wrote:
>>On Wed, 2020-02-05 at 07:44 +, Scott Kitterman wrote:
>>> Do syslog facilities really have to be addressed by number rather
>>than name? That seems like a horrible interface.
>>
>>Currently yes. Th
On Tuesday, 26 February 2019 1:19:35 AM AEDT Inaki Malerba wrote:
> [0] https://salsa.debian.org/salsa-ci-team/pipeline/blob/master/README.md
Thank you for providing this useful service.
My big concern though is that primary gitlab-runner 12.7.0 (HEAD)
on salsa-runner.debian.net f0fdd533 is not D
On Feb 05 2020, Anthony DeRobertis wrote:
> On February 5, 2020 9:49:36 AM UTC, Nikolaus Rath wrote:
>>On Feb 04 2020, Anthony DeRobertis wrote:
>>> Google has at some point had results from
>>> Gmail in the web search results (no idea if they currently do).
>>
>>Would you have a reference for t
On February 5, 2020 9:49:36 AM UTC, Nikolaus Rath wrote:
>On Feb 04 2020, Anthony DeRobertis wrote:
>> Google has at some point had results from
>> Gmail in the web search results (no idea if they currently do).
>
>Would you have a reference for this please?
Here is a news report from when th
On Wed, 2020-02-05 at 15:35:28 +0100, Ansgar wrote:
> On Wed, 2020-02-05 at 08:33 -0500, Sam Hartman wrote:
> > Steve, you're presuming that we would not create a new soname for
> > libc6 on architectures where we want a new time ABI.
>
> Isn't the libc ABI for some reason part of Debian's archite
On Wed, 2020-02-05 at 09:55 -0500, Sam Hartman wrote:
> > > > > > "Ansgar" == Ansgar writes:
>
> Ansgar> On Wed, 2020-02-05 at 08:33 -0500, Sam Hartman wrote:
> >> Steve, you're presuming that we would not create a new soname
> for
> >> libc6 on architectures where we want a new time
On Wed, Feb 05, 2020 at 01:25:58PM +0100, Didier 'OdyX' Raboud wrote:
> Le mercredi, 5 février 2020, 07.01:44 h CET Scott Kitterman a écrit :
> > Not particularly useful IMO. In /var/log/mail.log I can see log entries
> > from all the programs configured to log to the mail facility.
>
> Unless I'
> "Ansgar" == Ansgar writes:
Ansgar> On Wed, 2020-02-05 at 08:33 -0500, Sam Hartman wrote:
>> Steve, you're presuming that we would not create a new soname for
>> libc6 on architectures where we want a new time ABI.
Ansgar> Isn't the libc ABI for some reason part of Debian's
On Wed, 2020-02-05 at 13:32 +, Scott Kitterman wrote:
> > Currently yes. There is an upstream bug asking for a way to
> > specify
> > them by name[1], but nobody implemented it yet.
> >
> > I think a `--facility` option should be fairly easy to
> > implement. Just
> > adapt some code from th
On Wed, 2020-02-05 at 08:33 -0500, Sam Hartman wrote:
> Steve, you're presuming that we would not create a new soname for
> libc6 on architectures where we want a new time ABI.
Isn't the libc ABI for some reason part of Debian's architecture name?
uclibc-linux-amd64, musl-linux-i386, i386 are dis
On Wed, Feb 05, 2020 at 01:32:41PM +, Scott Kitterman wrote:
My impression so far is that the journalctl interface is a regression from what
we have now in every way I care about.
Great! Good thing you can just keep using rsyslogd.
On February 5, 2020 12:35:45 PM UTC, Ansgar wrote:
>On Wed, 2020-02-05 at 07:44 +, Scott Kitterman wrote:
>> Do syslog facilities really have to be addressed by number rather
>than name? That seems like a horrible interface.
>
>Currently yes. There is an upstream bug asking for a way to s
* Matt Zagrabelny [200204 21:27]:
> The contents of /var/log/journal will be binary files that journalctl
> will read. IIRC.
This is my objection to the systemd journal. Binary log files are
absolutely _horrible_ for the general user, but they are terrific for
large data centers.
In a large dat
Steve, you're presuming that we would not create a new soname for libc6
on architectures where we want a new time ABI.
That s not at all obvious to me.
It seems in the same level of drastic as the other options you are
considering.
So taking it off the table without discussion or consi
On Wed, 2020-02-05 at 07:44 +, Scott Kitterman wrote:
> Do syslog facilities really have to be addressed by number rather than name?
> That seems like a horrible interface.
Currently yes. There is an upstream bug asking for a way to specify
them by name[1], but nobody implemented it yet.
I
Le mercredi, 5 février 2020, 07.01:44 h CET Scott Kitterman a écrit :
> Not particularly useful IMO. In /var/log/mail.log I can see log entries
> from all the programs configured to log to the mail facility.
Unless I'm mistaken, exim4 logs nothing to /var/log/mail.log by default, only
to /var/lo
Steve McIntyre 于2020年2月4日周二 下午9:15写道：
>
> Hey folks,
>
> Apologies - I should have sent this mail quite a while back. :-/
>
> Arnd Bergmann (in CC) has been helping to drive a lot of work to solve
> the 2038 problem in the Linux world. I've spoken about this before,
> e.g. at DebConf17. He's been
Hi Norbert,
As you know, I cannot help to care about every topic about Debian + AI.
By chance I saw some interesting pending GSoC projects:
https://wiki.debian.org/SummerOfCode2020/Projects
Packaging SUSI.AI and dependencies for Debian
Develop Debian AI Voice Assistant Blend
For good wish,
Package: wnpp
Severity: wishlist
Owner: Elena ``of Valhalla''
* Package name: bepasty
Version : 0.5.0
Upstream Author : Bepasty team
* URL :
https://github.com/bepasty/bepasty-server/blob/master/AUTHORS
* License : BSD-2-Clause
Programming Lang: Python
Des
Hi,
On Wed, Feb 05, 2020 at 09:43:43AM +0100, Bastian Blank wrote:
> However, you most likely don't actually want to tail this specific file.
> It is a solution for a more abstract problem, e.g. "I want to see logs
> from Postfix". And this question got a different answer.
The appeal of mail.lo
Russ Allbery writes:
> Ansgar writes:
>
>> So maybe just recommend people to move to 64-bit architectures and put
>> 32-bit applications in a time namespace so they believe they are still
>> in 2001 ;-) 32-bit architectures will probably still be useful in
>> embedded contexts for a long time and
On 2020-02-05 08:12, Michael Biebl wrote:
journald has matured of the years and journalctl has become more
sophisticated with dealing with broken journal files, so I would be
very
much interested in your experience with more recent systemd versions.
Not quite the same issue, but I will note t
On Feb 04 2020, Anthony DeRobertis wrote:
> Google has at some point had results from
> Gmail in the web search results (no idea if they currently do).
Would you have a reference for this please?
Best,
-Nikolaus
--
GPG Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F
Hi Scott
On Wed, Feb 05, 2020 at 07:44:25AM +, Scott Kitterman wrote:
> >> Of course the fact that I can't use all the tools available to
> >manipulate text
> >> files to follow or analyze logs is problematic. If I'm using
> >journalctl, how
> >> do I replicate 'tail -f /var/log/mail.loog'?
On February 5, 2020 6:53:56 AM UTC, Michael Biebl wrote:
>Am 05.02.20 um 07:01 schrieb Scott Kitterman:
>> Of course the fact that I can't use all the tools available to
>manipulate text
>> files to follow or analyze logs is problematic.
>Fwiw, you can still run
>journalctl -f | grep bla | awk
On February 5, 2020 6:49:07 AM UTC, Michael Biebl wrote:
>Am 05.02.20 um 07:01 schrieb Scott Kitterman:
>
>> Not particularly useful IMO. In /var/log/mail.log I can see log
>entries from
>> all the programs configured to log to the mail facility. That way I
>can see
>> the interaction betwe
71 matches
Mail list logo
