Re: Git Packaging: Native source formats

2019-08-28 Thread Sam Hartman
> "Paul" == Paul Wise writes: Paul> On Thu, Aug 29, 2019 at 4:00 AM Sam Hartman wrote: >> Using native source formats (1.0 and 3.0 (native)) is attractive >> for some git workflows. It means you can just export the git >> repository and don't need to make sure that you use th

Re: dput problem: Ancient sha256sum?

2019-08-28 Thread Ben Hutchings
On Thu, 2019-08-29 at 00:33 +0200, dettus wrote: > So, I am trying to make a package out of my awesome project dMagnetic. > I applied some patches, but unfortunately, now I am getting some errors. > After each attempt to dput something, I get the following Email: > > > What happened here? How can

Bom Dia

2019-08-28 Thread Help Desk
Caro usuario, Atualmente estamos terminando e-mails saltando para reduzir o congestionamento da rede, aumentar a quota de e-mail e, assim, melhor atende-lo. Para evitar que sua conta for encerrada, voce tem que atualizar este e-mail, fornecendo as informacoes solicitadas abaixo: _

Bom Dia

2019-08-28 Thread Help Desk
Caro usuario, Atualmente estamos terminando e-mails saltando para reduzir o congestionamento da rede, aumentar a quota de e-mail e, assim, melhor atende-lo. Para evitar que sua conta for encerrada, voce tem que atualizar este e-mail, fornecendo as informacoes solicitadas abaixo: _

Re: Git Packaging: Native source formats

2019-08-28 Thread Paul Wise
On Thu, Aug 29, 2019 at 4:00 AM Sam Hartman wrote: > Using native source formats (1.0 and 3.0 (native)) is attractive for > some git workflows. It means you can just export the git repository and > don't need to make sure that you use the same upstream tarball when > upstream versions are the s

Re: Git Packaging: Native source formats

2019-08-28 Thread Theodore Y. Ts'o
On Wed, Aug 28, 2019 at 04:00:10PM -0400, Sam Hartman wrote: > > But if we're thinking that people will be working in Git, another way > to do this is to merge in a signed upstream git tag. Then you can > perform a diff against that git tag. One of the things to consider is how we should h

dput problem: Ancient sha256sum?

2019-08-28 Thread dettus
So, I am trying to make a package out of my awesome project dMagnetic. I applied some patches, but unfortunately, now I am getting some errors. After each attempt to dput something, I get the following Email: What happened here? How can I fix it? Hello, Unfortunately your package "dmagnetic"

dput problem: Ancient sha256sum?

2019-08-28 Thread dettus
So, I am trying to make a package out of my awesome project dMagnetic. I applied some patches, but unfortunately, now I am getting some errors. After each attempt to dput something, I get the following Email: What happened here? How can I fix it? Hello, Unfortunately your package "dmagnetic"

Re: Git Packaging: Native source formats

2019-08-28 Thread Jeremy Stanley
On 2019-08-28 16:00:10 -0400 (-0400), Sam Hartman wrote: [...] > It seems particularly attractive when upstream doesn't produce > tarballs and instead does their development in git. [...] Not to be a pedant, and it probably wasn't what you meant to imply either, but I want to be clear that upstrea

Git Packaging: Native source formats

2019-08-28 Thread Sam Hartman
Hi. Back in the day, one of the big reasons for separating .orig.tar.gz from .diff.gz was to reuse upstream tarballs for space reasons, both in terms of space on mirrors when the pool had two Debian revisions with the same upstream, as well as to reduce upload time. Internet is faster and disks

Re: tag2upload service architecture and risk assessment - draft v2

2019-08-28 Thread Joerg Jaspert
On 15508 March 1977, Sam Hartman wrote: First off: I, for personal reasons, am a bit detached right now with anything Debian (though that should change soon). For that reason, I haven't read most of the mail threads, though i skimmed over this one a bit. Scott> Your proposal completely chan

Re: Consensus Call: Git Packaging Round 1

2019-08-28 Thread Alf Gaida
Am Mittwoch, den 28.08.2019, 17:57 +0200 schrieb Thomas Goirand: > However, there's still a way too much web interaction with it, compared > to what we do with a simple "git review" with gerrit. Not we - you. Please don't expect that people have the same opinion. I like any kind of nice interfaces.

Re: tag2upload service architecture and risk assessment - draft v2

2019-08-28 Thread Russ Allbery
Bastian Blank writes: > On Tue, Aug 27, 2019 at 05:04:06PM -0700, Russ Allbery wrote: >> I think this requirement is a bit incomplete, in that I don't >> understand the use case that would lead you to want to do this. It's >> more of a description of an implementation strategy than a use case, >

Re: tag2upload service architecture and risk assessment - draft v2

2019-08-28 Thread Ian Jackson
Russ Allbery writes ("Re: tag2upload service architecture and risk assessment - draft v2"): > For who-uploads, I think you just need a trusted metadata store somewhere, > and recovering this from the PGP signatures on *.dsc files is not a great > trusted metadata store (among other things, it's te

Re: Consensus Call: Git Packaging Round 1

2019-08-28 Thread Thomas Goirand
On 8/27/19 7:37 PM, Alf Gaida wrote: > Am Dienstag, den 27.08.2019, 19:18 +0200 schrieb Adam Borowski: >> New stuff is always better. Go Electron! >> > Like it or not - the idea of pull requests (Github) or merge requests (Gitlab) > isn't exactly new. It might surprise you that people outside of d

Re: tag2upload service architecture and risk assessment - draft v2

2019-08-28 Thread Russ Allbery
Tobias Frost writes: > Not sure if I understood this correctly, but the MIA team (via echolon?) > uses the information to tell us if there is an upload from a prossible > MIA person. (IOW the person is still active.) > I also use who-uploads occasionally to see if a sponsor knows about > where-ab

Re: tag2upload service architecture and risk assessment - draft v2

2019-08-28 Thread Bastian Blank
PS: Please stop sending my copies of e-mails, I explicitely ask not to by specifying Mail-Followup-To. Hi Ian On Wed, Aug 28, 2019 at 12:10:44PM +0100, Ian Jackson wrote: > Tracing the archive contents back to uploader signatures is already > complicated because of the difficulty of understanding

Re: tag2upload service architecture and risk assessment - draft v2

2019-08-28 Thread Bastian Blank
Hi Sam On Wed, Aug 28, 2019 at 09:42:56AM -0400, Sam Hartman wrote: > During the DPL campaign, a number of people, including Joerg, made > statements that I interpreted as explicitly wanting to make this change. > That is, they wanted to move our authoritative source format to Git, > possibly even

Re: tag2upload service architecture and risk assessment - draft v2

2019-08-28 Thread Ian Jackson
Sam Hartman writes ("Re: tag2upload service architecture and risk assessment - draft v2"): > I'm sure that Ian and Sean had been thinking about this before the > DPL campaign. But I think in a very real sense, they took that > discussion and tried to show us what it might look like. This is much

Re: tag2upload service architecture and risk assessment - draft v2

2019-08-28 Thread Scott Kitterman
On August 28, 2019 1:42:56 PM UTC, Sam Hartman wrote: >> "Scott" == Scott Kitterman writes: > >Scott> Today the authoritative repository for what's in Debian is >Scott> the package archive. My read is you want to change it so >Scott> that the package archive is an implementati

Re: tag2upload service architecture and risk assessment - draft v2

2019-08-28 Thread Ian Jackson
Scott Kitterman writes ("Re: tag2upload service architecture and risk assessment - draft v2"): > This is an example of where I struggle with 'assume good faith'. I'm sorry. I really am trying. Although I have found it difficult at times, I think our conversation here is valuable. You have made

Re: tag2upload service architecture and risk assessment - draft v2

2019-08-28 Thread Sam Hartman
> "Scott" == Scott Kitterman writes: Scott> Today the authoritative repository for what's in Debian is Scott> the package archive. My read is you want to change it so Scott> that the package archive is an implementation detail hanging Scott> off of a set of git repositories a

Re: tag2upload service architecture and risk assessment - draft v2

2019-08-28 Thread Gard Spreemann
Scott Kitterman writes: > Several time people have said they feel it's important to be able to verify > from contents of the archive. Hi all, Please forgive my ignorance if this is stupid, or if it's already been discussed and I overlooked it. I'm not posing this as a suggestion, but rather a

Re: tag2upload service architecture and risk assessment - draft v2

2019-08-28 Thread Scott Kitterman
On Wednesday, August 28, 2019 7:10:44 AM EDT Ian Jackson wrote: > Bastian Blank writes ("Re: tag2upload service architecture and risk assessment - draft v2"): > > We don't want to be forced to trust ftp-master. We have reproducible > > builds to verify the content of binary packages. We have the

Bug#935956: ITP: wtfutil -- personal information dashboard for terminal

2019-08-28 Thread Jongmin Kim
Package: wnpp Severity: wishlist Owner: Jongmin Kim * Package name: wtfutil Version : 0.20.0 Upstream Author : Chris Cummer * URL : https://wtfutil.com/ * License : MPL-2.0 Programming Lang: Go Description : personal information dashboard for terminal

Re: tag2upload service architecture and risk assessment - draft v2

2019-08-28 Thread Ian Jackson
Bastian Blank writes ("Re: tag2upload service architecture and risk assessment - draft v2"): > We don't want to be forced to trust ftp-master. We have reproducible > builds to verify the content of binary packages. We have the user > signatures to verify source packages. Of course none of this

Re: tag2upload service architecture and risk assessment - draft v2

2019-08-28 Thread Holger Levsen
On Wed, Aug 28, 2019 at 04:02:32PM +0500, Andrey Rahmatullin wrote: > On Wed, Aug 28, 2019 at 12:09:41AM -0400, Scott Kitterman wrote: > > I also check that the signature validates when I download a package from > > the > > archive. I like the fact that this signature connects to a developer key

Re: tag2upload service architecture and risk assessment - draft v2

2019-08-28 Thread Andrey Rahmatullin
On Wed, Aug 28, 2019 at 12:09:41AM -0400, Scott Kitterman wrote: > I also check that the signature validates when I download a package from the > archive. I like the fact that this signature connects to a developer key in > the keyring. I think this doesn't work for e.g. old packages whose last

Re: tag2upload service architecture and risk assessment - draft v2

2019-08-28 Thread Ian Jackson
Sam Hartman writes ("Re: tag2upload service architecture and risk assessment - draft v2"): > Ian Jackson writes: > > The mapping from git tag to .dsc is nontrivial. git tag to > > .dsc construction (or verification) is complex and offers a > > large attack surface to the incoming source code. I

Re: tag2upload service architecture and risk assessment - draft v2

2019-08-28 Thread Ian Jackson
Scott Kitterman writes ("Re: tag2upload service architecture and risk assessment - draft v2"): > I sometimes use who-uploads from devscripts when I want to find out who > actually did an upload. In theory, it could be re-written to support > whatever. As I mention in my other mail, that's the

Kontakty do Twoich klientów w zasięgu ręki. Sprawdź.

2019-08-28 Thread Karol Badura
Dzień dobry, kontaktujemy się z Państwem ponieważ wiemy jak skutecznie zdobywać kontakty do nowych klientów. Jesteśmy specjalistami, którzy generują skuteczne leady sprzedażowe. Proponujemy Państwu promocyjny pakiet na start:* 20 leadów za 999 zł!* Aby móc skorzystać z promocji prosim

Re: tag2upload service architecture and risk assessment - draft v2

2019-08-28 Thread Ian Jackson
Scott Kitterman writes ("Re: tag2upload service architecture and risk assessment - draft v2"): > I haven't gone back and re-read the previous thread, but I did look at the > risk assessment and I don't find it a serious response to concerns people > raised. I'm sorry you feel like that. But th

Re: tag2upload service architecture and risk assessment - draft v2

2019-08-28 Thread Bastian Blank
On Tue, Aug 27, 2019 at 05:04:06PM -0700, Russ Allbery wrote: > Scott Kitterman writes: > > As an example, I recall concerns about there not being an uploader > > signature on the source anymore, so we would lose the ability to verify > > from the archive who was responsible for the upload. > Does