Re: BITS from the DPL For September/October 2019

[Wouter Verhelst]

On Tue, Oct 29, 2019 at 03:19:03PM -0700, Russ Allbery wrote:
> We've now had several years of essentially declining to make a decision
> and trying to see if the project can muddle through, and while I feel
> somewhat vindicated by the fact that this didn't immediately fall apart
> and has sort of worked, I think it's becoming increasingly untenable.  We
> now have contributors who are far-removed from the original debate and who
> may have only used a systemd-based Debian system and we do not have clear
> project consensus that sysvinit support is mandatory in new packages, so
> the support is starting to bitrot, and given the lack of clear project
> guidance, no one is clearly empowered to prevent it from bitrotting.

Hear hear.

While I was reading Sam's message, I was a bit apprehensive about having
a vote about this; but his arguments, and yours, make sense in that it
is a good idea to either tell people we're no longer interested in
multiple init systems as a project, or to empower those who want to work
on it that we, as a project, think it is a sensible idea to do so and
that not supporting alternative init systems should be considered an RC
bug.

(FWIW, even though one of my packages doesn't currently have an init
script where it should, I happen to think the latter is true; but it has
become very clear to me over the past few years that this opinion is far
from common in the project, and that is precisely the reason why this
vote would be a good idea).

Having said that,

Sam: I notice that you've not sent a draft of your GR proposal to the
-vote mailing list yet. It has been my experience over the years that
that is not generally a good idea. The DPL does have the power to bypass
much of the GR procedure, and in urgent situations this is probably a
good thing; but I believe that the drafting of GR ballots in the open on
a public mailinglist is actually an essential part of the whole GR
procedure, which allows people to form an opinion together, resulting in
fewer (but better) options on the ballot.

It is times when we are divided, such as in the case of GR 2004_004,
that this process breaks down and the number of options on the ballot
skyrockets. This is also the reason, I think, why ballots that are
drafted in secret almost always immediately receive amendments as soon
as they are proposed, thereby negating any perceived benefit that they
might have provided.

For that reason, I would like to urge you to draft the ballot in the
open, unless you think there is little time for this and you need to
have something to move forward urgently -- which would be something I
would disagree with.

Thanks,

-- 
To the thief who stole my anti-depressants: I hope you're happy

  -- seen somewhere on the Internet on a photo of a billboard

Re: BITS from the DPL For September/October 2019

[Russ Allbery]

Thomas Goirand  writes:

> The last time we've had a GR on init systems, the general response was
> that we don't want to vote, and we preferred the TC to decide.

I don't think the core questions here are technical questions.  I think
they're more fundamental questions of project direction and questions
about what burden we want to put on ourselves as package maintainers in
order to support a variety of init systems.  This seems like a good set of
issues to resolve democratically, at least for lack of a better
alternative.  Resolution by TC on this issue seems likely to lead to lead
to challenges to the TC's impartiality or legitimacy.  That's really not
very much fun to go through when you're on the TC.

We've now had several years of essentially declining to make a decision
and trying to see if the project can muddle through, and while I feel
somewhat vindicated by the fact that this didn't immediately fall apart
and has sort of worked, I think it's becoming increasingly untenable.  We
now have contributors who are far-removed from the original debate and who
may have only used a systemd-based Debian system and we do not have clear
project consensus that sysvinit support is mandatory in new packages, so
the support is starting to bitrot, and given the lack of clear project
guidance, no one is clearly empowered to prevent it from bitrotting.

The current Policy text is a mess, and everything it says on the topic is
essentially accidental, being left over from text that was added to
clarify how to support upstart, before the TC decision on the default init
system.  It's unclear what requirements Policy should actually set on
packages that want to ship daemons, and any attempt to hammer that out is
likely to be contentious and have great difficulty reaching consensus.

I think it was the right thing to do to refuse to make a clear long-term
decision at the time, when the project had just gone through a bruising
and awful argument.  Now that we have some distance and have seen how the
ecosystem has subsequently evolved, I think it's time to circle back and,
hopefully with more accumulated wisdom, a bit of emotional distance, and a
bit more calm, make the deferred decision.

If we're really going to continue to fully support sysvinit, we should
commit to doing so clearly and empower people to test that support and
report bugs of appropriate severity (and also to create a stronger
incentive for making that support easier to achieve).  If we're not, we
should unambiguously free people from doing additional work that they
don't want to do and can't test easily, and also more clearly communicate
the project's intentions so that our partners like Devuan can make
informed decisions about how to proceed.  The simmering uncertainty and
low-level tension of not having a decision eventually becomes its own
problem.

A GR may not be the best mechanism to make that decision, but I'm not sure
what method would be better.

-- 
Russ Allbery (r...@debian.org)  

Re: [RFC] Proposal for new source format

[Russ Allbery]

Ian Jackson  writes:

> Of course this means that the resulting source packages are not the "3.0
> (quilt)" patch queue source packages that many people (even some people
> who like git) say is important to them.

> A key design goal for dgit and my tag2upload proposal, is that (when
> used in the most usual way) it produces nice source packages like
> everyone is used to.

My recollection is that you found 3.0 (quilt) packages had a lot of edge
cases and strange interactions with Git that you've had to work around.

I think there may be some deep conflicts here between a source package
that is inherently a useful basis for work and modification (one of the
design goals of 3.0 (quilt), and also one of the things those of us who
like Git source packages have always wanted) and a source package that is
easy to reproducibly generate and contains as little complexity as
possible so that the archive software doesn't need to use any complex
tools.

As long as I can get at the richer representation of the source, I think I
don't really care what the archive distributes, but I can only speak for
myself.

My impression of Bastian's proposal is that his 4.0 looks a lot like 3.0
(native) with overlays, which at least reduces the necessary tools to the
compressor and tar, although tar is still richer than one would ideally
want and therefore kind of a mess from a reproducibility standpoint.

-- 
Russ Allbery (r...@debian.org)  

Re: BITS from the DPL For September/October 2019

[Thomas Goirand]

On 10/29/19 6:16 PM, Sam Hartman wrote:
> Init System Policy
> ==
> 
> last Bits mail, I talked about how I was considering whether we needed a
> GR on Init System Policy.

The last time we've had a GR on init systems, the general response was
that we don't want to vote, and we preferred the TC to decide.

If we have such vote again, I'll continue on this direction: I'd prefer
if we didn't have to vote.

Thomas

Re: [RFC] Proposal for new source format

[Ian Jackson]

Russ Allbery writes ("Re: [RFC] Proposal for new source format"):
> And therefore the goal of this proposal is to define a source package
> format that allows this to be done more easily than our current source
> package format allows?

Of course this means that the resulting source packages are not the
"3.0 (quilt)" patch queue source packages that many people (even some
people who like git) say is important to them.

A key design goal for dgit and my tag2upload proposal, is that (when
used in the most usual way) it produces nice source packages like
everyone is used to.

Ian.

-- 
Ian JacksonThese opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Bug#943791: general: laptop HP 15_bw0xx does not power-off properly

[Christian Quentin]

Package: general
Severity: normal

Dear Maintainer,

* when I ask Debian to stop (from Gnome), the shutdown sequence seems to follow
the usual steps, the a blank screen appears.The screen is not completely off.
The PC does not power-off.
* As the PC does not stop, I have to press the power button 10 seconds which
does not seem to be the best way to stop a computer.
* I would expect the shutdown sequence to power-off the computer completely.
* Hint : shutting down Windows 10 (also present on this computer) works fine.

Best regards and thanks for the fabulous work you do



-- System Information:
Debian Release: 10.1
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.19.0-6-amd64 (SMP w/2 CPU cores)
Kernel taint flags: TAINT_DIE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Re: [RFC] Proposal for new source format

[Russ Allbery]

Bastian Blank  writes:
> On Tue, Oct 29, 2019 at 12:19:03PM -0700, Russ Allbery wrote:

>> Could you help me understand what this would look like?  Is it something
>> like this workflow?
>> 
>> 1. tag2upload determines the local Git tree that should be uploaded as a
>>new source package.
>> 
>> 2. tag2upload locally constructs a source package from that Git tree.
>> 
>> 3. The uploading user signs the source package that tag2upload constructs.

> The uploading user signs the .dsc file that was constructed.

Ah, okay, so the idea is to either embed the full signed .dsc file in the
tag or to embed at least the signature (and have the server reconstruct
the corresponding .dsc file)?

>> 4. tag2upload pushes a rich tag to its upload server that contains enough
>>information to identify the Git tree that should be uploaded and that
>>includes the signature over the source package constructed from that
>>tree.
>> 
>> 5. The tag2upload server reconstructs the source package from Git,
>>attaches the signature, and then forwards both to dak.

> The server reconstructs the source, attaches the signed (by the user)
> .dsc file and signs the .changes file covering the whole upload itself.

Aha, I think this is new: dak would then be willing to accept a .changes
file signed by the tag2upload server as long as (I'm assuming the rules
here, please check) (a) this is a source-only upload, and (b) the .dsc
file is signed by a DD or DM.  And then the upload permission check would
be done against the identity of the .dsc signer rather than the .changes
signer?

-- 
Russ Allbery (r...@debian.org)  

Re: [RFC] Proposal for new source format

[Bastian Blank]

Hi Russ

On Tue, Oct 29, 2019 at 12:19:03PM -0700, Russ Allbery wrote:
> Could you help me understand what this would look like?  Is it something
> like this workflow?
> 
> 1. tag2upload determines the local Git tree that should be uploaded as a
>new source package.
> 
> 2. tag2upload locally constructs a source package from that Git tree.
> 
> 3. The uploading user signs the source package that tag2upload constructs.

The uploading user signs the .dsc file that was constructed.

> 4. tag2upload pushes a rich tag to its upload server that contains enough
>information to identify the Git tree that should be uploaded and that
>includes the signature over the source package constructed from that
>tree.
> 
> 5. The tag2upload server reconstructs the source package from Git,
>attaches the signature, and then forwards both to dak.

The server reconstructs the source, attaches the signed (by the user)
.dsc file and signs the .changes file covering the whole upload itself.

> 6. dak validates the signature on the source package and accepts the
>package.
> 
> And therefore the goal of this proposal is to define a source package
> format that allows this to be done more easily than our current source
> package format allows?

Yes.

Regards,
Bastian

-- 
Captain's Log, star date 21:34.5...

Bug#943785: ITP: python-pyjsparser -- Fast JavaScript parser written in Python

[Peter Wienemann]

Package: wnpp
Severity: wishlist
Owner: Peter Wienemann 

  Package name: python-pyjsparser
  Version : 2.7.1
  Upstream Author : Piotr Dabkowski 
  URL : https://github.com/PiotrDabkowski/pyjsparser
  License : MIT
  Programming Lang: Python
  Description : Fast JavaScript parser written in Python

pyjsparser is a fast JavaScript parser written in Python.

It is a dependency of python-js2py (see #943783).

This package will be team-maintained by the Debian Python Modules
Team.

Bug#943783: ITP: python-js2py -- JavaScript to Python translator

[Peter Wienemann]

Package: wnpp
Severity: wishlist
Owner: Peter Wienemann 

  Package name: python-js2py
  Version : 0.66
  Upstream Author : Piotr Dabkowski 
  URL : https://github.com/PiotrDabkowski/Js2Py
  License : MIT
  Programming Lang: Python
  Description : JavaScript to Python translator

Js2Py provides a JavaScript to Python translator and a JavaScript
interpreter written in Python.

It is a dependency of python-lark-parser (see #941657).

This package will be team-maintained by the Debian Python Modules
Team.

Re: [RFC] Proposal for new source format

[Sam Hartman]

> "Bastian" == Bastian Blank  writes:

>> I don't think this proposal is sufficiently well developed where
>> you're going to get much good feedback on debian-devel.

Bastian> What would be the correct location for it?

I'm fairly frustrated that you snipped the key part of my mail trying to
give you constructive feedback and ignored the point I'm trying to make.

The problem is not that you're bringing this up on debian-devel.

The problem is that your proposal IS NOT SUFFICIENTLY DEVELOPED.
Several people including me have given you feedback that we didn't get
it.  based on other responses I may understand what you were trying to
do better than when I read your original message.  But as it stands, I
think the point is not to present the proposal somewhere else.  I think
that those wanting this proposal need to do a bit more work before
presenting it to the community.

In particular, quoting my original message:
>I don't think this proposal is sufficiently well developed where you're
>going to get much good feedback on debian-devel.

>My recommendation:

>1) Consider Russ's comment.  Consider whether you still want to go
>forward.

[It sounds like this may have happened by now.]

>2) If so, find a small group of people who think your idea sounds good.
>Focus on fleshing things out.  Include use cases and how this would make
>the world better.


>3) Solicit review on such a fleshed out proposal.

I think there is a bunch of stuff surrounding the assumptions and goals
of your proposal that is currently in your head and not in the proposal.
I'm reasonably up to date on these discussions.  If my initial reaction
is confusion, others are going to have that reaction too.

Re: [RFC] Proposal for new source format

[Russ Allbery]

Bastian Blank  writes:

> We had that discussion already, it is about the possibility of
> reproducing the content of the upload.  The tag2upload proposal said
> they can't do it and everyone need to trust this service to do the right
> thing.  I like to solve this problem and allow such a tool/service to
> forward the trust information by reproducing the output.

Could you help me understand what this would look like?  Is it something
like this workflow?

1. tag2upload determines the local Git tree that should be uploaded as a
   new source package.

2. tag2upload locally constructs a source package from that Git tree.

3. The uploading user signs the source package that tag2upload constructs.

4. tag2upload pushes a rich tag to its upload server that contains enough
   information to identify the Git tree that should be uploaded and that
   includes the signature over the source package constructed from that
   tree.

5. The tag2upload server reconstructs the source package from Git,
   attaches the signature, and then forwards both to dak.

6. dak validates the signature on the source package and accepts the
   package.

And therefore the goal of this proposal is to define a source package
format that allows this to be done more easily than our current source
package format allows?

-- 
Russ Allbery (r...@debian.org)  

Re: [RFC] Proposal for new source format

[Bastian Blank]

On Tue, Oct 22, 2019 at 07:33:47AM -0400, Sam Hartman wrote:
> My initial reaction is that this is additional complexity in a direction
> that we don't need.

It is not a question of complexity.  It is a question of trust and who
we want and need to trust.

If we abolish the principle that we want to need little trust as
possible and be able to verify all the steps within the archive, then we
don't actually need the complexity.  But someone needs to stand up and
proclamate exactly that.  This is what no-one did.

It we don't want to do sacrifica that, we have to stick to a chain of
trust.

> Like Russ, I generally assume that VCS-like things are the future.
> I understand there is complexity there.

What is "VCS-like"?  Please define it.  A source package is no VCS, it
does not need to be.

E.g. dgit is not a VCS-like source package, as it solves a different
purpose to a source package we ship in the archive to all our users.

Because we are running around this concept for some time now, please
help me to actually understand what you mean with it.

> But I don't understand why this proposed format would be a step forward
> in a world where we care more about VCSes.  As an example, I don't
> understand how this would make things better for tag2upload.

We had that discussion already, it is about the possibility of
reproducing the content of the upload.  The tag2upload proposal said
they can't do it and everyone need to trust this service to do the right
thing.  I like to solve this problem and allow such a tool/service to
forward the trust information by reproducing the output.

> I don't think this proposal is sufficiently well developed where you're
> going to get much good feedback on debian-devel.

What would be the correct location for it?

Regards,
Bastian

-- 
Those who hate and fight must stop themselves -- otherwise it is not stopped.
-- Spock, "Day of the Dove", stardate unknown

Re: Building Debian source packages reproducibly (was: Re: [RFC] Proposal for new source format)

[Ian Jackson]

Helmut Grohne writes ("Re: Building Debian source packages reproducibly (was: 
Re: [RFC] Proposal for new source format)"):
> I think I'd trust the tag2upload service given the documentation you
> presented about it. I'm less faithful in all dgit installations being
> sane, sorry. We've run into too many builds in dirty chroots already.

That does make sense.  This is one of the ways that tag2upload is
better than dgit push.  (It is a shame that "integrity" concerns are
blocking integrity improvements.)

It would be possible to write a QA service which would verify Dgit
fields and automatically file RC bugs.  So far that hasn't seemed
necessary.

It would also be possible for dgit clone to verify the correspondence
itself, at the point where it honours the Dgit field.  Would that be a
useful feature for you ?  Of course it does mean downloading the
elements of the source package, which it currently doesn't need to do
if it finds a Dgit field, but there's no real difficulty.  (I wouldn't
make this the default!)

> > You do not need to talk to any random git servers.  The git tree is
> > available on a single official Debian server, the dgit git server.
> > The Dgit: field in the .dsc identifies the commitid.  The .dsc is of
> > course available via the signed apt repositories, as well as being
> > available from the ftpmaster data API.
> 
> I was not trying to imply dgit to be a random git server. Given that
> dgit (currently) only contains history for a fraction of packages, we
> still need to compare with Vcs-Git. Given enough time, dgit will have
> useful histories eventually.

Yes.  If tag2upload is deployed, I expect it to be very popular.

Until then Vcs-Git has all the problems you mention and many others
too: it is hard to reliably find the right tag (even the tag name is
not formally standardised!) and certainly nothing checks that the tag
corresponds in any particular way.  How it might correspond is
generally not even documented anywhere - at least, not anywhere
machine-readable.

> Hmm. I'm not sure whether I actually need the tag object. The commit id
> is what I really need. dak might need the tag object. I'll defer to
> others.

I think ftpmaster's concerns mean that dak would want the tag object
to redo the uploader identify verification, even though from my point
of view that would be a redundant check.  But it's simple to provide
the tag and there is some integrity improvement from doing so, so that
is what I am proposing.

Ian.

-- 
Ian JacksonThese opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Re: Building Debian source packages reproducibly (was: Re: [RFC] Proposal for new source format)

[Bastian Blank]

Hi Didier

On Mon, Oct 28, 2019 at 10:05:11AM +0100, Didier 'OdyX' Raboud wrote:
> Of course, all of this can only work if we can have, or make the ".git to 
> .dsc" conversion reproducible; hence my query.

Now, please read the first mail of this thread again.  Yes, maybe parts
of it are unclear, but we are way past the "we need this conversion"
stage.

Maybe we can stop running in circles around this concept and design
solutions.

Bastian

-- 
Prepare for tomorrow -- get ready.
-- Edith Keeler, "The City On the Edge of Forever",
   stardate unknown

Re: Building Debian source packages reproducibly (was: Re: [RFC] Proposal for new source format)

[Helmut Grohne]

Hi Ian,

On Tue, Oct 29, 2019 at 12:54:57PM +, Ian Jackson wrote:
> I wonder if I have misunderstood you, because:
> 
> The tag2upload proposal is based on dgit, which already provides this.
> dgit indeed defines an isomorphism between source packages and git
> trees, and dgit clone gives a git branch that is thus-isomorphic to
> the .dsc.  This is fundamental to dgit's design.

I get that this is the intention, but I don't see that this property can
be safely assumed. I see the Dgit field as a hint. It says "this source
package should be equivalent to this commit" without any guarantees of
this actually being the case. I guess that for all uploads performed
thus far, this is indeed the case, but it is not a requirement validated
by dak or any other trusted (by me) entity. We could easily end up with
an upload where the commit id is accidentally different. Everything that
we can be gotten wrong, we will eventually get wrong.

> With `dgit push', the isomorphism is checked on the maintainer's
> machine during `dgit push'.  With tag2upload it is ensured by the
> tag2upload service.  (When the uploader didn't use dgit, dgit clone
> does a .dsc import, thus ensuring the isomorphism.)

I think I'd trust the tag2upload service given the documentation you
presented about it. I'm less faithful in all dgit installations being
sane, sorry. We've run into too many builds in dirty chroots already.

> > This property allows me to start from a git tree that is
> > authenticated by dak rather than a random git tree on a random git
> > server of questionable origin.
> 
> You do not need to talk to any random git servers.  The git tree is
> available on a single official Debian server, the dgit git server.
> The Dgit: field in the .dsc identifies the commitid.  The .dsc is of
> course available via the signed apt repositories, as well as being
> available from the ftpmaster data API.

I was not trying to imply dgit to be a random git server. Given that
dgit (currently) only contains history for a fraction of packages, we
still need to compare with Vcs-Git. Given enough time, dgit will have
useful histories eventually.

> It is true that this doesn't give you precisely the *tag* object -
> just the commit.  Adding the objectid of the tag object to the .dsc
> Dgit: field would be easy, if that would be helpful to you.  (Please
> file a wishlist bug against dgit if so.)  Alternatively, dak could
> publish the tag object (in a similar way to how it publishes binary
> buildinfos).

Hmm. I'm not sure whether I actually need the tag object. The commit id
is what I really need. dak might need the tag object. I'll defer to
others.

Helmut

Re: Building Debian source packages reproducibly (was: Re: [RFC] Proposal for new source format)

[Ian Jackson]

Helmut Grohne writes ("Re: Building Debian source packages reproducibly (was: 
Re: [RFC] Proposal for new source format)"):
> In other words, I want these formats (source package and tagged git
> tree) to be isomorphic (minus history). This requirement is too strong
> since not every source package will have a corresponding tag, but when
> there is a tag, I want to safely go from source package to tag and back
> again and arrive where I started from.

I wonder if I have misunderstood you, because:

The tag2upload proposal is based on dgit, which already provides this.
dgit indeed defines an isomorphism between source packages and git
trees, and dgit clone gives a git branch that is thus-isomorphic to
the .dsc.  This is fundamental to dgit's design.

With `dgit push', the isomorphism is checked on the maintainer's
machine during `dgit push'.  With tag2upload it is ensured by the
tag2upload service.  (When the uploader didn't use dgit, dgit clone
does a .dsc import, thus ensuring the isomorphism.)

> This property allows me to start from a git tree that is
> authenticated by dak rather than a random git tree on a random git
> server of questionable origin.

You do not need to talk to any random git servers.  The git tree is
available on a single official Debian server, the dgit git server.
The Dgit: field in the .dsc identifies the commitid.  The .dsc is of
course available via the signed apt repositories, as well as being
available from the ftpmaster data API.

It is true that this doesn't give you precisely the *tag* object -
just the commit.  Adding the objectid of the tag object to the .dsc
Dgit: field would be easy, if that would be helpful to you.  (Please
file a wishlist bug against dgit if so.)  Alternatively, dak could
publish the tag object (in a similar way to how it publishes binary
buildinfos).

Note that there are *two* tag objects: 1. the canonical view:
the dgit view tag, which is simply-isomorphic to the source package.
2. the maintainer tag, which is on the maintainer's branch and refers
to a commit in maintainer branch format.

With dgit push these are both made during dgit push with the
maintainer's key.  With tag2upload the canonical view tag is made by
the tag2upload service, because it is that service which performs the
maintainer->canonical conversion.

Each maintainer workflow defines a different mapping between
maintainer views and canonical views.  The (currently supported[1])
workflows are all isomorphisms.  So it is possible in principle to
reverse the maintainer->canonical transformation (if you know the
workflow, which can be found in the tags) but there is not currently
code to do that.  I don't get the impression, however, that this is a
thing you feel you need ?  (Some form of reverse transformation would
be needed to automatically and workflow-agnostically handle MRs whose
submitter is using the canonical view.)

> This backwards-connection seems to be missing thus far, but I do find it
> important for the reasons above. Adding it would easily allow dak to
> validate the signature on the tag.

So, I'm not sure I understand what you think is missing.

Ian.

[1] I think with monorepo workflows the maintainer->canonical
conversion is generally irreversible, because it discards information
about source packages other than the one in question.  This wouldn't
block MR processing because MRs are deltas and by definition the other
parts of the monorepo aren't edited in the MR.  It does mean you
couldn't reconstruct the whole monorepo given just the canonical view.

(Arguably this means that the .dsc representation of a source package
from a git monorepo is not a PFM.  See arguments on -legal and
-project, passim.  But the canonical view dgit branch does contain the
whole of the monorepo in its history, in a discoverable way, so
doesn't have this issue.)

-- 
Ian JacksonThese opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Re: Building Debian source packages reproducibly

[Philipp Kern]

On 2019-10-29 08:32, Tobias Frost wrote:

On Mon, Oct 28, 2019 at 05:53:00PM +, Ian Jackson wrote:

(...)


For example, you would not be able to do this:
   git clone salsa:something
   cd something
   make some straightforward change
   git tag# } [1]
   git push   # }
Instead you would have to download the .origs and so on, and wait
while your machine crunched about unpacking and repacking tarballs,
applying patches, etc.



I'm missing a "and then I test my package to ensure it still works 
before

upload" step…

I wonder how someone should test their packages when they do
not build it locally.
And if they do (as they should), the advantages you line
out are simply not there.



More abstractly we do not do that for binNMUs either. My main worry here 
is that we are designing a solution which still precludes sourceful 
no-change NMUs, which would actually be the correct solution for 
consistent versioning across all architectures. Ubuntu exclusively does 
those and I still struggle how we would build such a service in Debian 
without facing exactly the same concerns as tag2upload. Maybe if dak 
itself would do it?


Kind regards
Philipp Kern

KLEINE HERINNERING : Uw Sinterklaaszakjes op maat - PETIT RAPPEL : Vos sachets St-Nicolas personnalisés

[DIPPRO bvba-sprl]

Voor uw personeel en/of voor uw klanten…. is de Sint er weer !!!

Pour votre personnel et/ou pour vos clients… St-Nicolas est de retour 

 

 

 

 

Meer info – Plus d’info : 02-583.56.40

 

Prijsaanvraag : i...@dippro.beof click hier

Demande de prix : i...@dippro.beou cliquez ici

 

 

De nr 1 in gepersonaliseerd snoepgoed

Le n°1 en confiserie personnalisée

 

www.dippro.be

 

 

bvba DIPPROsprl

Isabellastraat 28 - 1703 Dilbeek - BELGIUM

Tel. +32(0)2-583.56.40 - E-mail : i...@dippro.be

 

Privacy verklaring (GDPR) Déclaration de confidentialité

 

Hier Uitschrijven-désinscrireici





--
This email has been checked for viruses by AVG.
https://www.avg.com

Re: Summary: BLAS/LAPACK Ecosys Massive Update

[Mo Zhou]

On 2019-10-29 09:20, Benda Xu wrote:
> Does that imply the blas64 inside src:julia could be finally unbundled?

Further investigation needed. I'm still thinking of a better solution
than compiling a decicated openblas from src:openblas for julia.

Bug#943756: ITP: nomad-driver-podman -- Nomad taskdriver for Podman containers

[Dmitry Smirnov]

Package: wnpp
Severity: wishlist
Owner: Dmitry Smirnov 
X-Debbugs-CC: debian-devel@lists.debian.org, 
pkg-go-maintain...@lists.alioth.debian.org
Control: affects -1 src:nomad
Control: block -1 by 943743 930440

   Package name: nomad-driver-podman
Version: 0.0~git2019
Upstream Author: pascom GmbH & Co. KG
License: Apache-2.0
URL: https://github.com/pascomnet/nomad-driver-podman
Vcs-Browser: https://salsa.debian.org/go-team/packages/nomad-driver-podman
Description: Nomad taskdriver for Podman containers
 Podman driver for HashiCorp's Nomad.


signature.asc
Description: This is a digitally signed message part.

Re: Summary: BLAS/LAPACK Ecosys Massive Update

[Benda Xu]

Hi Mo,

Mo Zhou  writes:

> Hi fellow developers,
>
> A good news especially for Debian scientific computing users.
> I shall call it a massive update, even if the whole update
> was decomposed into many tiny steps where some of them
> had already been finished 1 year ago.
>
> [...]

Congratulation for the big achievement!  Thank you so much for
contributing jointly to Debian and Gentoo.

Does that imply the blas64 inside src:julia could be finally unbundled?

Cheers,
Benda

Re: Building Debian source packages reproducibly (was: Re: [RFC] Proposal for new source format)

[Tobias Frost]

Hi Ian,

On Mon, Oct 28, 2019 at 05:53:00PM +, Ian Jackson wrote:

(...)
 
> For example, you would not be able to do this:
>git clone salsa:something
>cd something
>make some straightforward change
>git tag# } [1]
>git push   # }
> Instead you would have to download the .origs and so on, and wait
> while your machine crunched about unpacking and repacking tarballs,
> applying patches, etc.


I'm missing a "and then I test my package to ensure it still works before
upload" step…

I wonder how someone should test their packages when they do
not build it locally.
And if they do (as they should), the advantages you line
out are simply not there.


-- 
 tobi
 


signature.asc
Description: PGP signature