Re: Updated proposal for improving the FTP NEW process

[Joerg Jaspert]

On 14967 March 1977, Gert Wollny wrote:

I so like proposals from people who have never ever done any of the work
they propose something one. BUt hey...

> (1) Given that all new source package come with an ITP bug, when a
> package must be rejected, the FTP team could CC this bug in the
> rejection message. This would have the advantage that for everyone
> interested in the package the information why the package was rejected
> can easily be found. In addition, For large packages, where a review
> takes more than one day, the reviewer could send messages to the ITP
> about problems the moment they are found, so maintainers could start to
> work on correcting the errors earlier.

If someone comes up with a patch to process-new which does this in a
halfway reliable way, it doesn't need a long time wasting thread on
devel to get it.

> (2) To improve the initial quality of uploads to NEW I also propose the
> introduction a (voluntary) review step: Someone who is interested in
> getting additional reviews to a package before uploading it to NEW
> could file a "Request for review" (RFR) bug against wnpp. Then those
> who are willing to review packages can step in and also have a common
> place to comment on problems of the package that need fixing. When
> someone satisfied with the package they add a comment to the bug
> "Reviewed-By: name ", and when doing the actual upload, the
> maintainer replicates these R-B messages in the changelog closing the
> RFR bug. For large packages one might also add a comment "subir/module
> X Reviewed-By: ..." to indicate only a partial review.
> This R-B- information could also be added to that persons QA page under
> a new section "Reviewed Uploads".

> In a way this replicates what sponsors do for uploads of non-DDs, but
> especially for large packages a second pair of eyes is always helpful.

And that is thankfully something everyone can just do (ask your peers
for review). And is something that got proposed tons of times. Never see
anything come from it.

> Implementing the first point is essentially up the the FTP team.

No its not, its up to the ones that want it to patch dak process-new.
That is, parsing the bug-close list (if any), finding out if thats
really an ITP, and if so, CC it on rejection/prod.
Note that this has to be automatic, if it requires us to enter anything,
it is doomed to fail.

-- 
bye, Joerg

Re: Updated proposal for improving the FTP NEW process

[Andrey Rahmatullin]

On Wed, Mar 07, 2018 at 06:02:10AM +, Chris Lamb wrote:
> Andrey Rahmatullin wrote:
> 
> > > > I know for a fact that quite regularly licence checks on binNEW packages
> > > > causes RC bugs to pop up.  I acknowledge it may be a burder for the ftp
> > > > team, but that reason alone probably deserves to keep binNEW as it is.
> > > 
> > > That would seem to justify some sort of randomized spot checks [..]
> >
> > Exactly.
> 
> Whilst it does seem a little odd, there is some merit the current system
> where packages get essentially-arbitrary chosen for a cursory glance by a
> member the FTP team.
> 
> The team is already rather time-limited so an expectation of DFSG-checks
> of random packages already in the archive seems a little optimistic.
"Let's abolish binary-NEW checks"
"They are useful to catch copyright problems as a byproduct"
"Maybe we should replace them with actual copyright checks on more
randomly selected packages"
"We don't have manpower"
"LET'S ABOLISH BINARY-NEW CHECKS"


-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: Updated proposal for improving the FTP NEW process

[Chris Lamb]

Andrey Rahmatullin wrote:

> > > I know for a fact that quite regularly licence checks on binNEW packages
> > > causes RC bugs to pop up.  I acknowledge it may be a burder for the ftp
> > > team, but that reason alone probably deserves to keep binNEW as it is.
> > 
> > That would seem to justify some sort of randomized spot checks [..]
>
> Exactly.

Whilst it does seem a little odd, there is some merit the current system
where packages get essentially-arbitrary chosen for a cursory glance by a
member the FTP team.

The team is already rather time-limited so an expectation of DFSG-checks
of random packages already in the archive seems a little optimistic.

(Identifying various types of NEWness might still be marginally useful for
categorising new.html and similar interfaces, mind you.)


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-

Re: Updated proposal for improving the FTP NEW process

[Adam Borowski]

On Tue, Mar 06, 2018 at 06:15:10PM +, Ian Jackson wrote:
> Adam Borowski writes ("Re: Updated  proposal for improving the FTP NEW 
> process"):
> > On Tue, Mar 06, 2018 at 03:17:11PM +, Ian Jackson wrote:
> > > IMO Debian's rules should require that the revision should be
> > > incremented (at least) when you have shared the previous revision with
> > > other people as part of your Debian work.  That includes people who
> > > are processing NEW, sponsors, etc.
> > 
> > With my one of most active sponsors hat on: the current policy is that a
> > version that has never hit the archive must not have a separate changelog
> > entry, unless there are non-negligible users (such as a derivative, upstream
> > repository or at least the package being deployed to multiple users at a
> > workplace).  A past history is more acceptable than repeated attempts for an
> > upload.
> 
> Certainly in the exceptions you list, a separate changelog entry is a
> good idea.

Yeah, but my point is that, except those cases, current consensus seems to
be that there should be no separate changelog entries, no versions and no
tags.

(I say "seems" because there was no formal vote or formal thread, but when a
sponsoree produces such a changelog, no one among usual sponsors ever said
anything to the contrary.)

> I don't see where this policy you are implementing is written down.
> It doesn't seem to exist in policy or even the dev ref.

Alas, same applies to most of conventions.  It would be good to have such
things documented rather than learned by osmosis, but describing processes
is something no one volunteers for.

> > A changelog bloated with every replaced attempt is hard to read; gaps in
> > version numbering that come without an explanation also raise an eyebrow
> > (thus such a gap needs a comment in the changelog).
> 
> How many replaced attempts are we typically talking about ?

Ten is a quite extreme case, but 3-4 are common.  (Obviously most uploads
get in on the first go.)

> When an attempt is replaced, the reviewer would no doubt like not only
> the whole new package, but a human-readable summary of what the
> submitter has intentionally changed.  How do you think that
> human-readable summary ought to be communicated to the reviewer ?

That's what we have RFS bugs.  Every publicly reviewed upload has a
permanent trail.  The majority of uploads go this way.

There's no requirement to ask for review publicly, but private channels also
allow adequate communication with the reviewer.  Heck, as someone who
sponsors ~10× as many uploads as I do myself, I tend to use the same routine
I do for sponsoring for my own uploads.  In this case, the communication is
entirely within my brain!

And, the summary is not what's being checked.  I for one tend to skim over
RFS mails with so little attention I sometimes miss remarks from the
sponsoree -- looking only at debian/changelog.  This is what I read
carefully, comparing what's written there with what's in debdiff vs the last
version in the archive.

Comparing debdiffs is the main manual part of review.  And why would I care
that the shed got repainted red then blue, if it was black the last time it
was in the archive and is pink now?  This kind of details is ok for untagged
commits in git, but neither the reviewer nor the end user are interested in
changes that have been superseded between tags/uploads.  The process that
led you to decide on pink might be interesting but it's not what is being
reviewed.

The less _irrelevant_ information, the less work for us.  If the talk is
archived on the RFS bug, there's no information loss either.

> I disagree that gaps in the version numbering require an explanation,
> but even if they do then that is not a problem.

Gaps can be useful, but most of the time they're unintentional, that's why
there's a need for a comment.
 
> (Of course that the Debian revision does not need to be a single
> integer.  If you want to distinguish various attempts from the
> accepted submissions one could write -1.1 or something.)

Uhm, that's reserved for NMUs.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀ 
⣾⠁⢠⠒⠀⣿⡁ A dumb species has no way to open a tuna can.
⢿⡄⠘⠷⠚⠋⠀ A smart species invents a can opener.
⠈⠳⣄ A master species delegates.

Re: Updated proposal for improving the FTP NEW process

[Sean Whitton]

Hello,

On Tue, Mar 06 2018, Andrey Rahmatullin wrote:

> On Mon, Mar 05, 2018 at 02:43:34PM -0700, Sean Whitton wrote:
>> If a package is maintained in git, then re-using a version number
>> means force-pushing a git tag
> Just don't tag uploads until they are accepted.

This means that uploading to new is no longer fire-and-forget.  That's
bad.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Re: Updated proposal for improving the FTP NEW process

[Holger Levsen]

On Tue, Mar 06, 2018 at 05:54:55PM +0100, Adam Borowski wrote:
> With my one of most active sponsors hat on: the current policy is that a
> version that has never hit the archive must not have a separate changelog
> entry, unless there are non-negligible users (such as a derivative, upstream
> repository or at least the package being deployed to multiple users at a
> workplace).  A past history is more acceptable than repeated attempts for an
> upload.
> 
> This is what I was taught, and what I not only recommend but also require of
> sponsorees.  There seems to be a concensus on -mentors that this is the
> right way.

with my sponsoring hat on, I will be unhappy if someone reuses version
numbers and I will ask to never do this again. I very much agree with
Ian's position that this is bad.

As a sponsor, I'm a non-negligible user and I want to sensible be able
to not having to again review stuff I already have reviewed.

If you have put it on mentors.d.n, it's out in the public.


-- 
cheers,
Holger


signature.asc
Description: PGP signature

Re: Updated proposal for improving the FTP NEW process

[Sean Whitton]

Hello,

On Tue, Mar 06 2018, Adam Borowski wrote:

> gaps in version numbering that come without an explanation also raise
> an eyebrow (thus such a gap needs a comment in the changelog).

I think this is the problem.

Ian's concern about non-identical but identically versioned source
packages flying around could be satisfied by bumping the version number
but retaining a single changelog entry.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Re: Rant about Debian reproducibility environment

[Steffen Nurpmeso]

Paride Legovini  wrote:
 |On 2018-03-01 18:17, Steffen Nurpmeso wrote:
 |> But last week Paride committed "fixes"[1] after having been
 |> prodded by some third party, and indeed, now S-nail is
 |> reproducible on all Debian test boxes.  The fix was to set the
 |> built-in identification for the OS build environment to all
 |> "Debian", i.e.>
 |>   OS=debian OSENV=debian OSFULLSPEC=debian
 |
 |I don't have very much to add to what people that are more knowledgeable
 |than me about reproducibility issues (and Debian in general) already said.
 |
 |While I've got hinted to look at those three variables in order to make
 |the package reproducible, the decision to generically set all three of
 |them to "debian" was mine. This can probably be made more specific
 |without breaking the reproducibility, but adding uname(2) information is
 |probably the right thing to do.

v14.9.8 added this, too.

 |Suggestions on how to improve the package (well, any of the packages I
 |maintain) are always welcome.

I hope you do not have too much trouble with it.
Ciao,

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

Re: (solved) Re: wireless fail after stretch installation

[Brian]

On Tue 06 Mar 2018 at 18:34:27 +, Ian Jackson wrote:

> bw writes ("Re: (solved) Re: wireless fail after stretch installation"):
> > I think the idea needs to be talked over a little better, because using 
> > e/n/i for wireless by default after first boot has implications if the 
> > user (who is clueless) later installs a desktop environment.
> 
> If installing a desktop environment, after putting the wireless in
> /e/n/i, does not work, then that is a bug in the desktop environment,
> surely ?

Most probably. But desktop environments were not the subject of this
thread. (Sorry for trying to keep on-topic).

> In practice I would expect the config in /e/n/i to keep working
> because nowadays network-manager will ignore things in /e/n/i.  The
> difficulty would only come if you
>   - used the installer to install a bare system over wifi

That difficulty is  exactly the subject of this thread. The rest of this
post is snipped because it side-steps addressing the issue. What is put
in /e/n/i ceases to work because it is obliterated by the installer for
reasons unknown.

One user calls it a "sick joke". After five years and with no attempt
to rectify the situation, I'm beginning to have sympathy with that view.

(Yes, I know we are all volunteers).

-- 
Brian.




>   - later install network-manager or wicd
>   - then expect the system to give you a gui prompt for new wifi
> networks, rather than expect to have to edit /e/n/i
> 
> It would be possible for the n-m and wicd packages to spot when this
> is happening and offer to take over the interface.  And I do think
> that in the absence of code to do that, it would be more important to
> make the barebones system work in the first place, than to improve the
> behaviour you later install n-m.
> 
> (I'm not sure if what I say about wicd is right.  I use n-m on
> machines I have where the user needs to switch between various network
> connections, wifi networks, etc.)
> 
> > I'd hate to see the bug tracker turned into a discussion forum though.  
> 
> The bug tyracker is precisely the right place to discuss how to solve
> a particular bug.  So I have CC'd it.
> 
> 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: Updated proposal for improving the FTP NEW process

[Lars Wirzenius]

On Wed, 2018-03-07 at 00:30 +0500, Andrey Rahmatullin wrote:
> On Tue, Mar 06, 2018 at 07:27:40PM +, Ian Campbell wrote:
> > > I know for a fact that quite regularly licence checks on binNEW packages
> > > causes RC bugs to pop up.  I acknowledge it may be a burder for the ftp
> > > team, but that reason alone probably deserves to keep binNEW as it is.
> > 
> > That would seem to justify some sort of randomized spot checks on the
> > archive, not arbitrarily focussing on the subset of packages which
> > happen to need a new binary package for some reason.
> 
> Exactly.

It's almost spring in northern Europe and with the lengthening day I
start getting many crazy ideas. Here's one: it would be truly awesome
if we could review each source package at least once per Debian
release cycle. I don't think that's possible, it would be awesome if
it were.

There is, in unstable, about 28000 source packages right now, if I'm
counting correctly. A release cycle is about two years. That's about
40 source packages per day, every day. That would require either a
very large number of extra volunteer reviewers, or automation.

If most upstreams were systemtically tagging (perhaps using SPDX)
their sources with licence information, or we had a mostly reliable
tool for deducing that information automatically, this might be
feasible.


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

Re: Updated proposal for improving the FTP NEW process

[Andrey Rahmatullin]

On Tue, Mar 06, 2018 at 07:27:40PM +, Ian Campbell wrote:
> > I know for a fact that quite regularly licence checks on binNEW packages
> > causes RC bugs to pop up.  I acknowledge it may be a burder for the ftp
> > team, but that reason alone probably deserves to keep binNEW as it is.
> 
> That would seem to justify some sort of randomized spot checks on the
> archive, not arbitrarily focussing on the subset of packages which
> happen to need a new binary package for some reason.
Exactly.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: Updated proposal for improving the FTP NEW process

[Ian Campbell]

On Tue, 2018-03-06 at 19:18 +0100, Mattia Rizzolo wrote:
> On Tue, Mar 06, 2018 at 06:34:28PM +0100, Adam Borowski wrote:
> > What might be reasonable is making the separation between binNEW and srcNEW
> > more obvious, especially for us on the other side.  This would also
> > encourage the ftpmasters to skip license checks for binNEW -- but again,
> > without knowing their workflow I'm not in a position to improve it.
> 
> I know for a fact that quite regularly licence checks on binNEW packages
> causes RC bugs to pop up.  I acknowledge it may be a burder for the ftp
> team, but that reason alone probably deserves to keep binNEW as it is.

That would seem to justify some sort of randomized spot checks on the
archive, not arbitrarily focussing on the subset of packages which
happen to need a new binary package for some reason.

Ian.

Re: (solved) Re: wireless fail after stretch installation

[Brian Potkin]

On Tue 06 Mar 2018 at 18:27:29 +, Ian Jackson wrote:

> Brian writes ("Re: (solved) Re: wireless fail after stretch installation"):
> > #694068, #696755, #727740 and #777439.
> 
> Thanks.
> 
> I have read the bug logs and Trent Buck's message here
>   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=694068#47
> seems to suggest a way forward.
> 
> Perhaps someone would care to write and test a patch to d-i's network
> configuration arrangements, to implement Trent's suggestion ?  I think
> that the people who don't have network-manager would probably prefer
> this to use ifupdown, and making a whole new udeb will be work, so
> Trent's second suggestion seems sensible.

I would hazard a guess and say that 100% of users would expect to be
able to use the network they have set up during installation, afterwards.
Without an ethernet interface on the machine it becomes resorting to
setting it up again (5%), resorting to -user or the internet from
another machine (20%) or some head-scratching followed by walking away.
(The percentages are rough estimates).
 
> > > > The plain and simple fact is that a user who installs over a wireless
> > > > link and does not have network-manager does not have any connectivity
> > > > to the internet after first boot. Long Wind solved the issue by taking
> > > > the advice given and Charlie S used his initiative and knowledge to
> > > > devise an /e/n/i file which replaced the one the installer had wiped
> > > > out.
> > > > 
> > > > This has been going on since Debian 7.0.0 and is not the first time the
> > > > issue has arisen here. Debian must be the only OS which deliberately
> > > > removes connectivity present during installation.
> 
> I have to say that the tone of this message is rather unfortunate.
> You make it sound like someone is deliberately breaking stuff.  That
> doesn't seem to be the case.

The message was written to -user. Besides having a really helpful bunch
of users, there can sometimes be a robustness and directness to the
exchanges. Don't let it put you off if you are used to a more gentile
environment.

I hadn't realised the breakage was accidental and unplanned. OTOH, I am
not in possession of the reasons behind it; apart from some conjecture,
they still remain unknown. As you will see from the bug record, even
Debian developers are mystified.

> Comparing to other distros can be very helpful but generalised
> statements that they don't have this bug is less useful than looking
> into how they solve the problem.

We don't know what the problem is.

-- 
Brian.

Bug#892205: ITP: magic-wormhole-transit-server -- Transit Relay server for Magic-Wormhole

[Antoine Beaupre]

Package: wnpp
Severity: wishlist
Owner: Antoine Beaupre 

* Package name: magic-wormhole-transit-server
  Version : 0.1.1
  Upstream Author : Brian Werner
* URL : https://github.com/warner/magic-wormhole-transit-relay
* License : MIT
  Programming Lang: Python
  Description : Transit Relay server for Magic-Wormhole

This repository implements the Magic-Wormhole "Transit Relay", a
server that helps clients establish bulk-data transit connections even
when both are behind NAT boxes. Each side makes a TCP connection to
this server and presents a handshake. Two connections with identical
handshakes are glued together, allowing them to pretend they have a
direct connection.

This server used to be included in the magic-wormhole repository, but
was split out into a separate repo to aid deployment and development.

--

will be in collab-maint, new dependency for wormhole.

Re: Updated proposal for improving the FTP NEW process

[Andrey Rahmatullin]

On Tue, Mar 06, 2018 at 06:15:10PM +, Ian Jackson wrote:
> > A changelog bloated with every replaced attempt is hard to read; gaps in
> > version numbering that come without an explanation also raise an eyebrow
> > (thus such a gap needs a comment in the changelog).
> 
> How many replaced attempts are we typically talking about ?
A lot?

> When an attempt is replaced, the reviewer would no doubt like not only
> the whole new package, but a human-readable summary of what the
> submitter has intentionally changed.  How do you think that
> human-readable summary ought to be communicated to the reviewer ?
As a reply to the email containing the review?

Please look at debian-mentors@ if you have additional questions. Thank
you.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: (solved) Re: wireless fail after stretch installation

[Ian Jackson]

bw writes ("Re: (solved) Re: wireless fail after stretch installation"):
> I think the idea needs to be talked over a little better, because using 
> e/n/i for wireless by default after first boot has implications if the 
> user (who is clueless) later installs a desktop environment.

If installing a desktop environment, after putting the wireless in
/e/n/i, does not work, then that is a bug in the desktop environment,
surely ?

In practice I would expect the config in /e/n/i to keep working
because nowadays network-manager will ignore things in /e/n/i.  The
difficulty would only come if you
  - used the installer to install a bare system over wifi
  - later install network-manager or wicd
  - then expect the system to give you a gui prompt for new wifi
networks, rather than expect to have to edit /e/n/i

It would be possible for the n-m and wicd packages to spot when this
is happening and offer to take over the interface.  And I do think
that in the absence of code to do that, it would be more important to
make the barebones system work in the first place, than to improve the
behaviour you later install n-m.

(I'm not sure if what I say about wicd is right.  I use n-m on
machines I have where the user needs to switch between various network
connections, wifi networks, etc.)

> I'd hate to see the bug tracker turned into a discussion forum though.  

The bug tyracker is precisely the right place to discuss how to solve
a particular bug.  So I have CC'd it.

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: (solved) Re: wireless fail after stretch installation

[Ian Jackson]

Brian writes ("Re: (solved) Re: wireless fail after stretch installation"):
> #694068, #696755, #727740 and #777439.

Thanks.

I have read the bug logs and Trent Buck's message here
  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=694068#47
seems to suggest a way forward.

Perhaps someone would care to write and test a patch to d-i's network
configuration arrangements, to implement Trent's suggestion ?  I think
that the people who don't have network-manager would probably prefer
this to use ifupdown, and making a whole new udeb will be work, so
Trent's second suggestion seems sensible.

> > > The plain and simple fact is that a user who installs over a wireless
> > > link and does not have network-manager does not have any connectivity
> > > to the internet after first boot. Long Wind solved the issue by taking
> > > the advice given and Charlie S used his initiative and knowledge to
> > > devise an /e/n/i file which replaced the one the installer had wiped
> > > out.
> > > 
> > > This has been going on since Debian 7.0.0 and is not the first time the
> > > issue has arisen here. Debian must be the only OS which deliberately
> > > removes connectivity present during installation.

I have to say that the tone of this message is rather unfortunate.
You make it sound like someone is deliberately breaking stuff.  That
doesn't seem to be the case.

Comparing to other distros can be very helpful but generalised
statements that they don't have this bug is less useful than looking
into how they solve the problem.

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: Updated proposal for improving the FTP NEW process

[Mattia Rizzolo]

On Tue, Mar 06, 2018 at 06:34:28PM +0100, Adam Borowski wrote:
> What might be reasonable is making the separation between binNEW and srcNEW
> more obvious, especially for us on the other side.  This would also
> encourage the ftpmasters to skip license checks for binNEW -- but again,
> without knowing their workflow I'm not in a position to improve it.

I know for a fact that quite regularly licence checks on binNEW packages
causes RC bugs to pop up.  I acknowledge it may be a burder for the ftp
team, but that reason alone probably deserves to keep binNEW as it is.

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
more about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature

Re: Updated proposal for improving the FTP NEW process

[Ian Jackson]

Adam Borowski writes ("Re: Updated  proposal for improving the FTP NEW 
process"):
> On Tue, Mar 06, 2018 at 03:17:11PM +, Ian Jackson wrote:
> > IMO Debian's rules should require that the revision should be
> > incremented (at least) when you have shared the previous revision with
> > other people as part of your Debian work.  That includes people who
> > are processing NEW, sponsors, etc.
> 
> With my one of most active sponsors hat on: the current policy is that a
> version that has never hit the archive must not have a separate changelog
> entry, unless there are non-negligible users (such as a derivative, upstream
> repository or at least the package being deployed to multiple users at a
> workplace).  A past history is more acceptable than repeated attempts for an
> upload.

Certainly in the exceptions you list, a separate changelog entry is a
good idea.

I don't see where this policy you are implementing is written down.
It doesn't seem to exist in policy or even the dev ref.

> A changelog bloated with every replaced attempt is hard to read; gaps in
> version numbering that come without an explanation also raise an eyebrow
> (thus such a gap needs a comment in the changelog).

How many replaced attempts are we typically talking about ?

When an attempt is replaced, the reviewer would no doubt like not only
the whole new package, but a human-readable summary of what the
submitter has intentionally changed.  How do you think that
human-readable summary ought to be communicated to the reviewer ?

I disagree that gaps in the version numbering require an explanation,
but even if they do then that is not a problem.

(Of course that the Debian revision does not need to be a single
integer.  If you want to distinguish various attempts from the
accepted submissions one could write -1.1 or something.)

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: Updated proposal for improving the FTP NEW process

[Bastian Blank]

Hi Steve

Please don't top-post and fix the length of your lines.

On Tue, Mar 06, 2018 at 10:22:22AM -0600, Steve Robbins wrote:
> Or: change the mechanism to avoid a trip through NEW for simple cases that 
> Chris outlined: new binary or soname bump.  Reserve NEW for truly new things.

Can you describe an algorithm that can destinguish between an soname
change and some other change?

Bastian

-- 
We do not colonize.  We conquer.  We rule.  There is no other way for us.
-- Rojan, "By Any Other Name", stardate 4657.5

Re: Updated proposal for improving the FTP NEW process

[Adam Borowski]

On Tue, Mar 06, 2018 at 10:22:22AM -0600, Steve Robbins wrote:
> Or: change the mechanism to avoid a trip through NEW for simple cases that
> Chris outlined: new binary or soname bump.  Reserve NEW for truly new
> things.

Let's not try to be wiser than ftpmasters: if, despite the increased
workload, they haven't expressed such an obvious wish yet, they obviously
value sanity checks here.

What might be reasonable is making the separation between binNEW and srcNEW
more obvious, especially for us on the other side.  This would also
encourage the ftpmasters to skip license checks for binNEW -- but again,
without knowing their workflow I'm not in a position to improve it.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀ 
⣾⠁⢠⠒⠀⣿⡁ A dumb species has no way to open a tuna can.
⢿⡄⠘⠷⠚⠋⠀ A smart species invents a can opener.
⠈⠳⣄ A master species delegates.

Re: Updated proposal for improving the FTP NEW process

[Steve Robbins]

Or: change the mechanism to avoid a trip through NEW for simple cases that 
Chris outlined: new binary or soname bump.  Reserve NEW for truly new things.


On March 5, 2018 9:00:06 AM CST, "W. Martin Borgert"  wrote:
>Quoting Chris Lamb :
>>> In many cases, there is an issue open about the new binary package
>>
>> (In my experience, there is not.)
>>
>>> When there is no bug report open at all, well, bad luck.
>>
>> Well, possbibly, but if one is investing time and effort in changing
>a
>> process it seems a shame not to cover these cases IMHO. :)
>
>True. Proposal: Maintainer should make sure they have a bug open about
>any new binary packages and close them with the upload. If they forget
>this "goto badluck;".

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Re: (solved) Re: wireless fail after stretch installation

[Brian]

On Tue 06 Mar 2018 at 15:01:03 +, Ian Jackson wrote:

> Brian writes ("Re: (solved) Re: wireless fail after stretch installation"):
> > The plain and simple fact is that a user who installs over a wireless
> > link and does not have network-manager does not have any connectivity
> > to the internet after first boot. Long Wind solved the issue by taking
> > the advice given and Charlie S used his initiative and knowledge to
> > devise an /e/n/i file which replaced the one the installer had wiped
> > out.
> > 
> > This has been going on since Debian 7.0.0 and is not the first time the
> > issue has arisen here. Debian must be the only OS which deliberately
> > removes connectivity present during installation.
> 
> Can someone point me to the bug report about this ?
> 
> Ian.

#694068, #696755, #727740 and #777439.

-- 
Brian.

Re: Updated proposal for improving the FTP NEW process

[Adam Borowski]

On Tue, Mar 06, 2018 at 03:17:11PM +, Ian Jackson wrote:
> Scott Kitterman writes ("Re: Updated  proposal for improving the FTP NEW 
> process"):
> > If you consider it absurd to not increment the revision due to
> > changes that never made it in the archive, then I don't know where
> > it stops.
> 
> IMO Debian's rules should require that the revision should be
> incremented (at least) when you have shared the previous revision with
> other people as part of your Debian work.  That includes people who
> are processing NEW, sponsors, etc.

With my one of most active sponsors hat on: the current policy is that a
version that has never hit the archive must not have a separate changelog
entry, unless there are non-negligible users (such as a derivative, upstream
repository or at least the package being deployed to multiple users at a
workplace).  A past history is more acceptable than repeated attempts for an
upload.

This is what I was taught, and what I not only recommend but also require of
sponsorees.  There seems to be a concensus on -mentors that this is the
right way.

I'm not arguing that a change here is unacceptable, merely describing
currently agreed upon convention.

A changelog bloated with every replaced attempt is hard to read; gaps in
version numbering that come without an explanation also raise an eyebrow
(thus such a gap needs a comment in the changelog).

You can have private history published publicly in git, but it's best to
refrain from pushing a tag until the version has been accepted.  That's why
git doesn't push tags by default when you push the branch they apply to.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀ 
⣾⠁⢠⠒⠀⣿⡁ A dumb species has no way to open a tuna can.
⢿⡄⠘⠷⠚⠋⠀ A smart species invents a can opener.
⠈⠳⣄ A master species delegates.

Re: Updated proposal for improving the FTP NEW process

[Ian Jackson]

Scott Kitterman writes ("Re: Updated  proposal for improving the FTP NEW 
process"):
> If you consider it absurd to not increment the revision due to
> changes that never made it in the archive, then I don't know where
> it stops.

IMO Debian's rules should require that the revision should be
incremented (at least) when you have shared the previous revision with
other people as part of your Debian work.  That includes people who
are processing NEW, sponsors, etc.

I hope the reasons why this is a sensible place to stop are obvious.

If you want to increment the revision for every git commit then as far
as I'm concerned that's between you and your computer :-).  (There are
sometimes good reasons for doing so when you are building binaries...)

>  I admit, this was hyperbole, but Ian's extremism annoys
> me.  I should do a better job of ignoring it.

I'm sorry to post messages that you feel like you should be ignoring.
Thanks for arguing back anyway.

> I'm not sure you actually read what I wrote since I wrote that I
> thought REQUIRING the revision to be bumped was a bad idea and you
> gave me a case where it made sense to do so.  Nowhere in this thread
> have I ever said bumping the revision is inherently a bad idea.

I am indeed suggesting that there should be a requirement.

Ultimately the purpose of the version number is so that we can
distinguish packages with the same name and different contents.  These
distinctions need to be made on users' systems and also in the proper
archive suites, but they also need to be made in NEW and in the
sponsorship queue, and when sharing informally.

Once source packages are being thrown about (in NEW, in sponsorship,
etc.), having different packages which are apparently identical (same
filenames, same metadata) is unreasonably confusing.  It requires the
people who deal with them to invent ad-hoc overlay versioning schemes.

This is all very silly[1] IMO, when we could use the existing version
number field to identify the version of the package.

AFAICT the only reasons people don't bump the revision when they
re-upload to NEW are:

 * Some of our upload tools DTWT by default if you bump the version
   number and/or add changelog stanzas, for versions that didn't make
   it to the archive suite in question.  This is IMO a tooling
   problem.  (You could use my tool and not suffer this problem; or
   you could improve the other tools.)

 * Some people have a misplaced sense that not using -1 or whatever is
   "untidy".  It's true that it does leave visible traces, but those
   visible traces are the record of what really happened.  Depending
   on exactly what happened, they can be useful in the future.  They
   are certainly not harmful.  This relates to my general refrain that
   integers are cheap and we should not be afraid to "waste" a few.

I hope you find this message more to your taste.  [1] despite my use
of the word "silly".

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: (solved) Re: wireless fail after stretch installation

[Ian Jackson]

Brian writes ("Re: (solved) Re: wireless fail after stretch installation"):
> The plain and simple fact is that a user who installs over a wireless
> link and does not have network-manager does not have any connectivity
> to the internet after first boot. Long Wind solved the issue by taking
> the advice given and Charlie S used his initiative and knowledge to
> devise an /e/n/i file which replaced the one the installer had wiped
> out.
> 
> This has been going on since Debian 7.0.0 and is not the first time the
> issue has arisen here. Debian must be the only OS which deliberately
> removes connectivity present during installation.

Can someone point me to the bug report about this ?

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#892190: ITP: python-user-agents -- A Python library that provides an easy way to identify devices like mobile phones, tablets and their capabilities by parsing (browser) user agent strings.

[Andre Bianchi]

Package: wnpp
Severity: wishlist
Owner: Andre Bianchi 
Control: block 745661 by -1
Control: block 796777 by -1

* Package name: python-user-agents
  Version : 1.1.0
  Upstream Author : Selwin Ong, Loisaida Sam Sandberg
* URL : https://pypi.python.org/pypi/user-agents
* License : MIT
  Programming Lang: Python
  Description : A Python library that provides an easy way to identify 
devices like mobile phones, tablets and their capabilities by parsing (browser) 
user agent strings.

user_agents is a Python library that provides an easy way to
identify/detect devices like mobile phones, tablets and their
capabilities by parsing (browser/HTTP) user agent strings. The goal is
to reliably detect whether:

- User agent is a mobile, tablet or PC based device
- User agent has touch capabilities (has touch screen)

user_agents relies on ua-parser _ to
do the actual parsing of the raw user agent string.

This is a dependency for Weblate (https://weblate.org/):
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=745661
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=796777

The idea is to maintain it inside the Debian Python Modules Team.
Everyone is welcome to help. :)

Bug#892182: ITP: siphashc -- siphashc is a python c-module for siphash, based on floodberry's version.

[Andre Bianchi]

Package: wnpp
Severity: wishlist
Owner: Andre Bianchi 
Control: block 745661 by -1
Control: block 796777 by -1

* Package name: siphashc
  Version : 1.0
  Upstream Author : Eli Janssen, Carlo Pires, Michal Čihař
* URL : https://github.com/WeblateOrg/siphashc/
* License : MIT
  Programming Lang: C, Python
  Description : siphashc is a python c-module for siphash, based on 
floodberry's version

SipHash is a family of pseudorandom functions (a.k.a. keyed hash
functions) optimized for speed on short messages. 

siphashc is a python c-module for siphash, based on floodberry's
version.

This is a dependency for Weblate (http://weblate.org): 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=745661
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=796777

I have asked upstream why they chose siphashc over alternatives, and the
answer was: "It was third party package where I later took over the
maintainership, that's why it's separate. I was looking at other
alternatives as well, but the problem is that the only maintained
alternative which exposes siphash is python-nacl and that performs way
worse due to working as generic hash and producing strings instead of 64
bit integers which we need. Overall it was quite big performance drop in
my tests."

The plan is to maintain it inside the Debian Python Modules Team.
Everyone is welcome to help. :-)

Re: A proposal for improving transparency of the FTP NEW process

[Dominique Dumont]

On Saturday, 3 March 2018 07:54:00 CET Lars Wirzenius wrote:
> We have licencecheck, and if that isn't good enough, we can improve
> it.

That's my cue to advertise "cme update dpkg-copyright" that uses licencecheck 
output to provide a debian/copyright file

See [1] for details (and limitations)

HTH

[1] 
https://github.com/dod38fr/config-model/wiki/Updating-debian-copyright-file-with-cme

-- 
 https://github.com/dod38fr/   -o- http://search.cpan.org/~ddumont/
http://ddumont.wordpress.com/  -o-   irc: dod at irc.debian.org

Re: Rant about Debian reproducibility environment

[Paride Legovini]

On 2018-03-01 18:17, Steffen Nurpmeso wrote:
> 
> But last week Paride committed "fixes"[1] after having been
> prodded by some third party, and indeed, now S-nail is
> reproducible on all Debian test boxes.  The fix was to set the
> built-in identification for the OS build environment to all
> "Debian", i.e.>
>   OS=debian OSENV=debian OSFULLSPEC=debian

I don't have very much to add to what people that are more knowledgeable
than me about reproducibility issues (and Debian in general) already said.

While I've got hinted to look at those three variables in order to make
the package reproducible, the decision to generically set all three of
them to "debian" was mine. This can probably be made more specific
without breaking the reproducibility, but adding uname(2) information is
probably the right thing to do.

Suggestions on how to improve the package (well, any of the packages I
maintain) are always welcome.

Cheers,

Paride

Re: [Pkg-javascript-devel] three.js_80+dfsg2-2_amd64.changes REJECTED

[Ian Jackson]

Pirate Praveen writes ("Re: [Pkg-javascript-devel] 
three.js_80+dfsg2-2_amd64.changes REJECTED"):
> On വ്യാഴം 01 മാർച്ച് 2018 05:45 വൈകു, Ian Jackson wrote:
> > For the avoidance of doubt, I don't have a problem with the specific
> > decision of ftpmaster here.  
> 
> Coming back to this specific rejection (I have already started a
> discussion on policy question in d-policy), do you agree node-backbone
> (and all other packages currently in archive and match the criteria of
> rejection used for node-three, ie, a binary package with just symlinks
> and a package.json) should be removed from the archive? If that is the
> general agreement, I will file serious bugs against these packages
> (already in the archive for years).

Firstly, I don't think this follows.  It is right that the criteria
for accepting a new package are stricter than the criteria for
removing an existing one.

Secondly, the actual question of what should be in these packages is
precisely a policy question.  We should decide what our policy is and
then apply it.  (Of course examples can illuminate the policy.)  So I
don't think your queston can be answered until we know what the policy
should be.

By "don't disagree" I don't mean "agree".  I mean that the rejection
seems plausible and I haven't seen enough arguments to have a firm
opinion.

If the policy we decide on is that the packages with just symlinks
should be folded into the packages they provide links to, then yes
those packages should be fixed but it is IMO unlikely to be sensibly
considered an RC bug.

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#892157: ITP: itk4 -- [incr Tk] OOP extension version 4 for Tk

[Sergei Golovan]

Package: wnpp
Severity: wishlist
Owner: Sergei Golovan 

* Package name: itk4
  Version : 4.1.0
  Upstream Author : Tcl Core Team
* URL : http://incrtcl.sourceforge.net/itk/index.html
* License : BSD (the same as Tcl)
  Programming Lang: C, Tcl
  Description : [incr Tk] OOP extension version 4 for Tk

This is the next major version of [incr Tk] - a companion of [incr Tcl]
(an OOP extension for Tcl) suitable for building complex widgets.
It will replace the itk3 package after all the reverse dependencies
switch to it.

The package is to be maintained under Debian Tcl/Tk team.

Bug#892155: ITP: itcl4 -- [incr Tcl] OOP extension for Tcl

[Sergei Golovan]

Package: wnpp
Severity: wishlist
Owner: Sergei Golovan 

* Package name: itcl4
  Version : 4.1.1
  Upstream Author : Tcl Core Team
* URL : http://incrtcl.sourceforge.net/itcl/
* License : BSD (the same as for Tcl itself)
  Programming Lang: C, Tcl
  Description : [incr Tcl] OOP extension for Tcl

This is the next major version of the [incr Tcl] Tcl extension
with object oriented paragigm support. It will eventually
replace the itcl3 package.

This package is planned to be maintained under the Debian Tcl/Tk team.