Re: RFC: raising ca-certificates package Priority to standard or important

https://www.eff.org/https-everywhere https is getting everywhere. If you don't have ca's you cannot process them properly. I think https working is going to be important even for almost all embedded cases. Most iot deployments include something like calling the mothership, which ought to be

Re: What to do when DD considers policy to be optional? [kubernetes]

On Fri, Apr 10, 2020 at 1:12 PM Russ Allbery wrote: > Dmitry Smirnov writes: > > > Let's remember that Kubernetes was never in "stable" to begin with. > > > This is not to say that it couldn't be useful in "testing", "unstable" > > or even "experimental". Many packages that may be considered

Re: What to do when DD considers policy to be optional? [kubernetes]

doesn´t this whole discussion just mean that k8 should just not be in Debian? It should be a third party package, perhaps with a third party repo, and just not be in Debian at all. If any means of packaging for a Debian release results in a package that is essentially unsupported by upstream...

Re: email backend for fedmsg

Most Sarrracenia stuff is tied to AMQP, but next-gen messages are called v03 (version 3) they use a JSON payload for all the information, and that makes it somewhat protocol independent. There is also a 500 line MQTT demo that implements a file replication network, using the same JSON messages,

Re: email backend for fedmsg

MQTT is the best thing going for interop purposes. On Tue, Mar 24, 2020 at 1:20 PM Jeremy Stanley wrote: > On 2020-03-24 13:09:35 -0400 (-0400), Peter Silva wrote: > [...] > > We could talk about the merits of various protocols (I see fedmsg > > uses ZeroMQ) but that is

Re: email backend for fedmsg

hi, totally different take on this... We could talk about the merits of various protocols (I see fedmsg uses ZeroMQ) but that is a deep rabbit hole... to me, fedmsg looks like it is making a ZeroMQ version of a broker (which is a bit ironic given the original point of that protocol) trying to

Re: RFC: Replacing vim-tiny with nano in essential packages

try ssh into a windows machine. the termcaps are all manner of fun. On Thu, Mar 19, 2020 at 7:23 AM Adam Borowski wrote: > On Thu, Mar 19, 2020 at 11:34:10AM +0500, Lev Lamberov wrote: > > Ср 18 мар 2020 @ 18:52 Adam Borowski : > > > > > Alas, our ed is basically: > > > #!/bin/sh > > > while

Re: RFC: Replacing vim-tiny with nano in essential packages

fwiw... anyone who knows vi already knows ed, it's just the line mode commands. you save the : and that's it. uh... fwiw, I had a mainframe typish system I had to admin 30 years ago... being a mainframe, had no working TERMCAP, and the editor was ed. yeah, a bit painful, the only command that

Re: RFC: Replacing vim-tiny with nano in essential packages

so maybe we just add nano-tiny as an option to vim-tiny. because we understand vim is not newbie friendly, but for all the old hands, nano is not friendly to us. 234K is a small price to pay. On Mon, Mar 16, 2020 at 7:27 PM Guus Sliepen wrote: > On Mon, Mar 16, 2020 at 01:02:47PM +, Wookey

Re: moving mg from salsa to github?

fwiw, looking at the repo on github. There are tags. They're just dates, Ideally one would get an idea of what the tags are from upstream, but you could just git clone using a tag. Also github allows you to easily get a tarball given a tag: wget https://github.com/hboetes/mg/tarball/20180927

Re: Wifi en debian

translation of spanish email: disappointed wifi didn´t work out of the box with Debian thinking wifi drivers are missing. answer: I don't think the drivers are the problem for wifi in Debian. Most, if not all wireless chipsets have open source drivers which are included. The problem is that

Re: [Idea] Debian User Repository? (Not simply mimicing AUR)

On Sun, Apr 7, 2019 at 11:10 PM Ben Finney wrote: > Peter Silva writes: > > > […] the launchpad.net model, which supports backporting seamlesslly > > and allows to support the same version on all distro versions, works > > better for us. This is something a debian ve

Re: [Idea] Debian User Repository? (Not simply mimicing AUR)

On Sun, Apr 7, 2019 at 8:41 PM Roberto C. Sánchez wrote: > On Sun, Apr 07, 2019 at 05:50:37PM -0400, Peter Silva wrote: > > > >Hiring debian devs to get the packages into debian proper could make > >sense. One thing that dampens our enthusiasm for that at the mome

Re: [Idea] Debian User Repository? (Not simply mimicing AUR)

On Sun, Apr 7, 2019 at 1:27 PM Roberto C. Sánchez wrote: > On Sun, Apr 07, 2019 at 10:13:58AM -0400, Peter Silva wrote: > >fwiw, our organization doesn't have any debian devs. We have a few > >packages that we develop and deploy > >for our internal need

Re: is Wayland/Weston mature enough to be the default desktop choice in Buster?

> > > > * RockPro64, used as a desktop (I'm typing these words on it): > > armsoc. GNOME no workie. > > Hows the 3D performance on this? > > https://www.cnx-software.com/2018/08/27/rockpro64-rk3399-board-linux-review-ubuntu-18-04/ 71fps or es2gears? but that was a year ago... likely better

Re: [Idea] Debian User Repository? (Not simply mimicing AUR)

fwiw, our organization doesn't have any debian devs. We have a few packages that we develop and deploy for our internal needs, and make available to the internet with public repositories. they are (perhaps not perfectly) debian compliant packages, but we aren't blessed debian devs (and frankly

Re: Bug#877900: How to get 24-hour time on en_US.UTF-8 locale now?

iso_en ? That sounds smart... English for most of the world that aren't necessarily native English speakers? https://en.wikipedia.org/wiki/International_English Use ISO dates and stuff, and pick a random spelling. As a Canadian, I'm pretty sure about colour, but unclear about whether we should

Re: FHS: Where to store user specific plugins / code

another option: -- it is best practice for daemons/services not to run as root. They should have an application specific user. -- some tools can be run in a systemish way by a specific user, but also by other users in a less official way (think web server on a high port instead of port 80.) --

Re: Call for volunteers: FTP Team

PNQteam naturally leads to Pinocchio ... which isn't in Toy Story, but you can't have everything. On Thu, Aug 17, 2017 at 6:05 PM, Geert Stappers wrote: > On Thu, Aug 17, 2017 at 11:22:03PM +0200, Joerg Jaspert wrote: >> On 14767 March 1977, Jonathan Carter wrote: >> >>

Re: A radically different proposal for differential updates

Isn't there kind of a universal issue that tar and compression happen sort of in the wrong order? Wouldn't it make more sense to make files that were .gz.tar (ie. compress the files individually, then have an index into them via tar.) Then tar works perfectly well for extracting individual files

Re: Proposal: A new approach to differential debs

<christ...@iwakd.de> wrote: > On 08/13/2017 07:11 PM, Peter Silva wrote: >>> apt by default automatically deletes packages files after a successful >>> install, >> >> I don't think it does that. > > The "apt" command line tool doesn

Re: Proposal: A new approach to differential debs

server-xorg-video-nvidia_375.66-1_amd64.deb -rw-r--r-- 1 root root 3101944 Jul 16 17:14 xserver-xorg-video-nvidia_375.66-2~deb9u1_amd64.deb blacklab% On Sun, Aug 13, 2017 at 12:43 PM, Julian Andres Klode <j...@debian.org> wrote: > On Sun, Aug 13, 2017 at 10:53:16AM -0400, Peter Silv

Re: Proposal: A new approach to differential debs

You are assuming the savings are substantial. That's not clear. When files are compressed, if you then start doing binary diffs, well it isn't clear that they will consistently be much smaller than plain new files. it also isn't clear what the impact on repo disk usage would be. The most