Re: Reasons for keeping Coin3D (libcoin20) at version 1.0.4?

[Steve Robbins]

Quoting Gunnar Wolf <[EMAIL PROTECTED]>:


Gunnar Wolf dijo [Thu, Oct 05, 2006 at 03:29:30PM -0500]:

Hi,
(...)


GAH!

Sorry... Please ignore this mail.

I felt I researched thoroughly on coin's status, didn't it? Well, yes,
but I didn't pay attention that there are two different source
packages: coin (providing Coin3D 1.0 series) and coin2 (providing
2.4.5, the newest upstream release).


Correct.  To answer your previous questions: I am still actively  
maintaining both the coin 1.x and coin 2.x series.  I do welcome help  
with these packages (indeed, any of my packages), whether it be  
co-maintainer or a new maintainer.  And the reason for keeping coin  
1.x around is (from memory): it is more strictly adhering to SGI's  
reference implementation of Inventor, and there is a license  
difference (coin 1 is LGPL, coin 2 is GPL).




Bad Gunnar. Bad Gunnar.

/me hides.


No need to castigate yourself.  I don't mind being asked such  
questions, especially when they have easy answers ;-)


I hope that coin2 satisfies your needs.

Cheers,
-Steve

Re: apt-get cron job

[Steve Robbins]

On Tue, 21 Mar 2000, Peter Cordes wrote:

>  Any suggestions/comments?  I'd be surprised if I'm the first person to
> think of this, but I didn't see anything that suggested it anywhere.

One suggestion: for some people, it makes sense to use the `apt-move'
package after downloading the .debs.  Apt-move will move the .debs out of
the cache into a Debian archive hierarchy & naming convention.

This is quite handy for folks that have another machine or two connected
via a local net: you can point the second machine's apt at the local
archive.


-Steve

Re: RBL report..

[Steve Robbins]

On Sun, 26 Mar 2000, Michael Neuffer wrote:

> * Jason Gunthorpe ([EMAIL PROTECTED]) [000326 08:45]:
> >[...]
> >ORBS - 314
> >   Comparing connections it is found that 3970 out of 40236 connection
> >   attempts would have been blocked. This can be roughly considered to be
> >   3970 emails blocked.
> >[...] 
> > ORBS deserves special mention because of their insane hit count, I don't
> > know what that is about but ORBS would block 10% of the mails we get. I
> > think it is without question that the majority of those blocks are
> > legitimate mails. ORBS is also almost completely inclusive of the RSS and
> > RBL.
> 
> ORBS has a slightly different (broader and maybe better) goal then the 
> the others. It actively scans the net for open mail relays,

This is misleading.  What ORBS does is *test* mail servers to ensure that
it *is* an open relay, before adding the relay's address to the list.

They do NOT (according to the web page) "scan the net" for open relays.  
Rather, the list is generated solely from reports (via web or email) from
folks that have been spammed.

> warns 
> the operators of these machines multiple times with exact descriptions 
> of what they are doing, trying to accomplish (ie closing open mail relays)
> which problems have been found, how to fix them (plus necessary pointers
> to other sites) and how to get of the list. Only then the machine is added 
> to the list.

However, if a relay remains in their list for some time (I forget how
long, but it's on the order of a month or two), the address is moved on to
a public list of open relays.  Presumably, the spammers know about this
list, so the probability of being used as a spam relay increases immensely
as time goes on.

-Steve

Re: My recent bug's and continuing effort to debconf-ize Debian

[Steve Robbins]

On Fri, 1 Sep 2000, Sean 'Shaleh' Perry wrote:

> c) *eventually* there will be a debconf server(right word?) which network
> admins can install.  This will have the answers stored in it and then when
> boxes need to know an asnwer, they query debconf and it queries the server.
> This way, you can do unattended installs of an entire computer lab.

Until that happens, is there a quick 'n' dirty way to replicate answers?

I'd be happy just copying the file(s) that make up the database from
an installed machine to the new machine.  Is it possible?  Which files?

-S




-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: RFC: GUI tools for common Debian admin tasks

[Steve Robbins]

Frederic,

I think that easier config is a worthy goal.  I have long mused about how
to teach a single tool about the myriad config files.  But I'm too lazy to
actually write one.

On Thu, 7 Sep 2000, Frederic Peters wrote:

> Seth Cohn wrote :
> > >So, yes, why reinvent the wheel, if there are allready n^x conftools
> > >around with a new one popping up monthly (webmin, COAS, linuxconf,
> > >debconf, yast, ..., ..., ...) ? It's not going to make anything
> > >easier.
>
> > Agreed.  If you want to do something USEFUL, write a better webmin, debconf
> > or linuxconf module.
>
>  - webmin: I think it is useful (and nice) not to have to launch mozilla
>to add an user or change a password.
>  - debconf: dpkg-reconfigure users ? debconf is there to configure
>applications and I don't want to replace it at all. It is just not
>suited for some tasks
>  - linuxconf: Marco d'Itri sent a comment I agree with (excepted for
>the insecure part where I don't have enough knowledge to judge)

"why reinvent the wheel" was one of my first reactions, too.

I'm glad to see some discussion of alternatives.  I hope that someone
(Frederic?) will take notes and write a summary on a web page somewhere.
I'm reminded of the document that someone (Joey Hess?) wrote comparing
packaging tools.

I'd like to see a little more in depth comparison, though.  For example,
someone says that linuxconf "sucks, is buggy, and insecure"; but does that
make it harder to fix than to reinvent?  Why?  It is said to be "tainted
by redhat", but how about fixing it to allow customization for different
distribution flavours?  

I used linuxconf as an example, but the same questions apply to all other
config tools.  Gnome, for instance, has a config tool.  I'm sure kde does
too.  Presumably you want a tool independent of these desktops, but it
would be great if it interacted with Gnome's tool.  Maybe one could even
separate the back-end from the GNOME front-end, and re-use it?

Even if you can't use a single line of code from any of the existing
projects, studying them allows you to steal worthwhile ideas and learn
from their mistakes.

-S




-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: apt-move problem

[Steve Robbins]

On Thu, 7 Sep 2000, Peter S Galbraith wrote:

> My current problem with apt-move is that it wants to delete every
> single deb file I have (instead of only those that have never
> versions on hand).  Also, it makes completely empty Packages.gz
> files for me.

I dunno about the first, but I have seen the second problem.  In my case,
it was caused by a bug in dpk-scanpackages (from dpkg-dev); see bug #51479
in BTS.

-S




-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

d-d digest

[Steve Robbins]

Hi,

I've not received anything via debian-devel-digest since Friday, yet
there are new messages visible via the web.

Can someone check if the digesting mechanism is broken?

-S




-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

What's the status of webmin?

[Steve Robbins]

Hello,

What's up with webmin?

In the archives of debian-devel, I see at least
three threads that started with a message from someone
proposing to package webmin, and quickly followed by
Jaldhar H. Vyas claiming that he is working on it.

However, I can't find webmin at packages.debian.org.

In July, Jaldhar said he had uploaded version 0.80.
Debian Weekly News for October 25th states that webmin
was a new package that week.

So it must have been uploaded at one time.

I poked around ftp-master.debian.org with "locate webmin",
and I see that Jaldhar's July upload of version 0.80 got pulled because it was 
in "main" when it should have been in "contrib".  Moreover, Ola Lundqvist
uploaded version 0.82 around the end of October, but it also seems to have
been pulled.

What happened?
-Steve

autoremovals a month early?

[Steve Robbins]

What gives?

Saturday: digikam 4:5.9.0-1 is marked for autoremoval from testing on 
2019-08-26

Sunday: digikam REMOVED from testing

-S
--- Begin Message ---
FYI: The status of the digikam source package
in Debian's testing distribution has changed.

  Previous version: 4:5.9.0-1
  Current version:  (not in testing)
  Hint: 
# 20190721
# temporary removal to unblock readline transition

The script that generates this mail tries to extract removal
reasons from comments in the britney hint files. Those comments
were not originally meant to be machine readable, so if the
reason for removing your package seems to be nonsense, it is
probably the reporting script that got confused. Please check the
actual hints file before you complain about meaningless removals.

-- 
This email is automatically generated once a day.  As the installation of
new packages into testing happens multiple times a day you will receive
later changes on the next day.
See https://release.debian.org/testing-watch/ for more information.
--- End Message ---
--- Begin Message ---
digikam 4:5.9.0-1 is marked for autoremoval from testing on 2019-08-26

It (build-)depends on packages with these RC bugs:
931970: gphoto2: autopkgtest failure block readline migration


--- End Message ---

Re: Re: Bug#1052004: libcbor: requires source-only upload to transition

[Steve Robbins]

It would be lovely to get this enabled!  It's a pain point for me also, on
occasion.

-Steve

Re: Is there a mip64el machine available for debugging?

[Steve Robbins]

Oh. I did use Eller -- but the architecture is listed as mipsel.  I need 
mips64el 

On August 21, 2022 10:54:44 p.m. CDT, Sebastiaan Couwenberg 
 wrote:
>On 8/22/22 05:36, Steven Robbins wrote:
>> The list at https://db.debian.org/machines.cgi suggests all available 
>> machines
>> are "buildd" and restricted.
>
>eller.debian.org is the mipsel/mips64el porterbox.
>
>Kind Regards,
>
>Bas
>
>-- 
> GPG Key ID: 4096R/6750F10AE88D4AF1
>Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1
>

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

Re: Why do we list individual copyright holders?

[Steve Robbins]

On Sunday, December 31, 2017 8:42:29 PM CST Stuart Prescott wrote:
> Vincent Bernat wrote:

> > Lintian is full of opinions. For example, I often get:
> > 
> > W: python-pysnmp4-doc: extra-license-file
> > usr/share/doc/python-pysnmp4-doc/html/_sources/license.txt
> 
> That is not an opinion, it is a statement of fact that there is an
> additional licence file in the package

True.  But it is an *opinion* that this is a fact that one ought to care 
about.  


-Steve


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

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

[Steve Robbins]

On Thursday, March 1, 2018 6:15:08 AM CST Ian Jackson wrote:

> But when a submitter disagrees with a REJECT, and asks for a review,
> IMO submitter is entitled to a longer explanation, and there should
> explicitly be an opportunity for other ftpmasters to agree or dissent.

That would be nice.  I'm still waiting for clarity about the Boost rejection.

 
> I think this could be easily implemented as follows:
> 
> When decision of ftpmaster is challenged by the submitter, or
> clarification is requested, the original decisionmaker should write a
> draft response and circulate it amongst the ftpmaster colleagues.

I'd propose rather that the deliberations be public, like the rest of Debian.  
Like the technical committee.

Generally agree with the rest of your proposal.

-Steve


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

A proposal for improving efficiency of the FTP NEW process

[Steve Robbins]

On Friday, March 2, 2018 6:00:57 AM CST Gert Wollny wrote:

> I'd like to make a proposal how
> transparency and also the interaction from non ftp-master members to
> review packages could be improved.

I have an orthogonal proposal to enhance efficiency: stop re-examining each 
new SOVERSION of a shared library package.

The NEW queue is said to be for "when a new package is uploaded to Debian for 
the first time" [1].  For many packages, uploading a new upstream version goes 
straight into unstable.  This is not true, however, for shared library 
packages.  Because of the convention that a shared library package name 
contains the SOVERSION and the convention that any new binary package requires 
going through NEW -- each and every new upstream makes a trip through NEW.  
This is unnecessary work for FTP masters and unnecessary friction.

Solution: change the convention to "any new SOURCE package requires a trip 
through NEW".

[1] https://wiki.debian.org/NewQueue

Regards,
-Steve


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

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

[Steve Robbins]

On Friday, March 2, 2018 6:15:54 AM CST Lars Wirzenius wrote:

> I'm not involved with the ftp master team in any way, except I
> occasionally make them do work by uploading things that go to thew NEW
> queue. In the past decade ago, the NEW processing has almost always
> been fast, and when it hasn't, it's been due to issues like a Debian
> release happening.
> 
> I assume that the reason my packages have been processed is due to one
> of two reasons: a) I get quoted on LWN several times a year, so I'm a
> celebrity and get special treatment

I expect that's it.  

Or possibly you have a more generous notion of "fast".  Currently there are 
five or six dozen packages waiting more than 2 months.  That's not fast in my 
books.

-Steve


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

FTP Policy Development

[Steve Robbins]

On Friday, March 2, 2018 11:07:39 PM CST Scott Kitterman wrote:
> On Friday, March 02, 2018 09:44:04 PM Steve Robbins wrote:
> > On Thursday, March 1, 2018 6:15:08 AM CST Ian Jackson wrote:
> > > But when a submitter disagrees with a REJECT, and asks for a review,
> > > IMO submitter is entitled to a longer explanation, and there should
> > > explicitly be an opportunity for other ftpmasters to agree or dissent.
> > 
> > That would be nice.  I'm still waiting for clarity about the Boost
> > rejection.
> 
> This is my fault.  I had planned (and still do) on working on getting some
> clarification around the copyright notification issue.  Unfortunately, I've
> gotten distracted by a few other things, but I still plan on working on it.

Well, I don't think it is your fault.  I myself have several times sat down to 
write a follow-up -- with an actual proposal, not just complaining :-) -- but 
also got distracted.  We're all busy.  But I am heartened to hear that you are 
working on it.  And I welcome the recent proposals by Ian and by Gert.

To me, one of the puzzling aspects is why the FTP policy work has been so 
secretive.  The release team has a mailing list, tech committee has a mailing 
list.  There is Debian Policy list.  It doesn't seem in congruence that the 
ftp team is making their policy behind closed doors.  Should it not flow from 
Debian Policy and be debated on open lists?

Or maybe it is all open and I simply haven't found it.  If so, I would 
gratefully accept pointers.  Concretely: where would one find the 
deliberations behind https://ftp-master.debian.org/REJECT-FAQ.html ?

-Steve
P.S.  If I didn't strike the right tone in this email, then I do apologise.  
It is honestly not intended to be antagonistic, though I admit it does sound a 
bit whiny.


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

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

[Steve Robbins]

My preferred algorithm is dead simple : if the source package is the same, it 
is not NEW.

Sorry for the top -post.  My mobile device client is deficient.

On March 6, 2018 11:34:29 AM CST, Bastian Blank  wrote:
>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

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

Re: Updated proposal for improving the FTP NEW process

[Steve Robbins]

I think the suggestion of randomized spot checking is meant to replace - not 
add - to the present system of checking that penalizes uploads of existing 
source but new binaries.  So human resources should not be the issue. 

I would imagine that the packages currently being selected are not arbitrary -  
they are weighted towards library code.  Is that fair to say? 



On March 7, 2018 12:02:10 AM CST, 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.
>
>(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
>   `-

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

Re: FTP Policy Development

[Steve Robbins]

Sure I do understand how things work.  I'm not suggesting that ALL discussions 
need be public - specifically I was not meaning deliberations on any given 
case.  

But I do think that general policy discussions should involve the entire debian 
community - as is done for Debian Policy Manual.



On March 7, 2018 7:03:54 PM EST, Gunnar Wolf  wrote:
>Steve Robbins dijo [Sat, Mar 03, 2018 at 01:15:35PM -0600]:
>> (...)
>> To me, one of the puzzling aspects is why the FTP policy work has
>been so 
>> secretive.  The release team has a mailing list, tech committee has a
>mailing 
>> list.  There is Debian Policy list.  It doesn't seem in congruence
>that the 
>> ftp team is making their policy behind closed doors.  Should it not
>flow from 
>> Debian Policy and be debated on open lists?
>> 
>> Or maybe it is all open and I simply haven't found it.  If so, I
>would 
>> gratefully accept pointers.  Concretely: where would one find the 
>> deliberations behind https://ftp-master.debian.org/REJECT-FAQ.html ?
>
>Ummm...
>
>Not that I know much about how ftp-masters work internally. But I have
>been on several other Debian teams. In general, all decisions are
>taken in the public - But it is by far not uncommon to resort to
>private communication for many of the non-obvious, contentious
>cases. There are *always* cases where you want to discuss something
>without the affected actors being part of the loop.
>
>Yes, Debian as a whole strives for openness, and you will often see
>calls to "get out of private" whenever interesting discussions taking
>place. But I would perfectly understand and support a ftp-master
>workflow that routinely involves private communication - Their
>decisions, although non-personal in nature, can be *felt* as personal
>attacks. 

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

Finding all projects on salsa to which I contribute

[Steve Robbins]

Is there a button or query that will show all projects that list me as 
uploader?   I'm looking for the same list I get on the PTS packages overview 
page.

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

Re: Finding all projects on salsa to which I contribute

[Steve Robbins]

Thanks James.   But I think your suggestion will lead me to the projects one at 
a time.  I'm looking for a view on salsa of all such projects. 


On March 10, 2018 5:31:10 PM EST, James McCoy  wrote:
>On Sat, Mar 10, 2018 at 04:30:56PM -0500, Steve Robbins wrote:
>> Is there a button or query that will show all projects that list me
>as
>> uploader? I'm looking for the same list I get on the PTS packages
>overview
>> page.
>
>Follow the links on the VCS column of the PTS' DDPO overview?  Assuming
>they've all been uploaded with correct Vcs-* information.
>
>Cheers,
>-- 
>James
>GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7  2D23 DFE6 91AE 331B A3DB

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

Help: gpb buildpackage no longer builds

[Steve Robbins]

In the last upload of googletest -- December 2016 -- I successfully used "gbp 
buildpackage".  Today, with zero changes, it fails to actually do the build: 
it skips from configuration to running tests.

The rules file [1] is, I think, pretty simple: there are overrides for  
dh_auto_configure , _test, _install, and _clean; nothing else.  Am I missing 
something?

[1] https://salsa.debian.org/debian/googletest/blob/master/debian/rules

Thanks,
-Steve


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

Re: Help: gpb buildpackage no longer builds

[Steve Robbins]

On Sunday, April 8, 2018 1:36:50 PM CDT Emilio Pozuelo Monfort wrote:

> Which version of debhelper are you building with? 

11.2

> The cmake support was
> recently broken and just fixed in debhelper 11.2.1, so make sure you get
> that.

Thanks for the tip!  I'll upgrade and try again.
-Steve



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

Removal philosophy

[Steve Robbins]

On Saturday, April 21, 2018 4:05:27 PM CDT Jeremy Bicha wrote:
> But I think if we had that philosophy, we
> wouldn't ever remove anything until identified security concerns force
> it out.

I don't see anything wrong with that philosophy.

Assuming someone is willing to maintain a package and it isn't causing harm 
("security concerns"), why would one want to remove it?

-S


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

gbp import-orig has defeated me

[Steve Robbins]

Hi,

I would like to update the googletest salsa repo [1] with upstream 1.8.1.  So 
I downloaded the tarball and ran "gbp import-orig" on it.  That appeared to 
work, but "gbp buildpackage" fails with

  dpkg-source: error: aborting due to unexpected upstream changes ...

from the diffs, my guess is there is some line ending issue.  I've pushed 
everything to salsa repo.  Hoping someone here can take a look and point me in 
the right direction.

For good measure, I tried creating a brand new git repo to import the tarball, 

  git init
  gbp import-orig --pristine-tar ../googletest_1.8.1.orig.tar.gz
  ... copy debian dir from the salsa repo & commit ...
  gbp buildpackage

and ended up in the same situation!

Thanks,
-Steve

[1] https://salsa.debian.org/debian/googletest

Re: gbp import-orig has defeated me

[Steve Robbins]

On Monday, October 1, 2018 10:35:01 PM CDT Shengjing Zhu wrote:

> I think you have configured your git to auto convert the line ending
> when commit.
> 
> In the pristine-tar tarball,
> $ file googletest-release-1.8.1/googlemock/msvc/2005/gmock.sln
> googletest-release-1.8.1/googlemock/msvc/2005/gmock.sln: UTF-8 Unicode
> (with BOM) text, with CRLF line terminators
> 
> In your master and upstream branch
> $ file googletest-1.8.1/googlemock/msvc/2005/gmock.sln
> googletest-1.8.1/googlemock/msvc/2005/gmock.sln: UTF-8 Unicode (with BOM)
> tex
> 
> I import the orig tarball in my env, these files are CRLF in my git tree.
> I'm not sure what git config influences this, but maybe core.eol,
> core.autocrlf, core.safecrlf.
> I'm just using the default values, at least my `git config --list`
> output didn't show anything related.

I think you've pointed in the right direction.  I have started reading through 
https://adaptivepatchwork.com/2012/03/01/mind-the-end-of-your-line/ 
and discovered that I have one non-default: core.autocrlf=input.  According to 
the article, this is recommended for linux.  Maybe that's not true; or maybe I 
just need to generate a .gitattributes file?  I'll try that tomorrow.

Thanks,
-Steve

Re: gbp import-orig initially defeated me [but now I've won]

[Steve Robbins]

Hi,

Thanks to all!  I have gotten past the issue and created a build now.


On Tuesday, October 2, 2018 6:59:54 AM CDT Ian Jackson wrote:

> I think you should not set any of these options.  I disagree with the
> discussion in that article surrounding the suggestion to use
> core.autocrlf=input.  Almost no-one should do this on Linux.

Hmm.  Good to know.  I changed back to the default.  I can't recall when I 
changed it, but I suspect it was in response to reading the github page: 
https://help.github.com/articles/dealing-with-line-endings/

> In the Debian context, if the orig tarball contains files with cr-lf
> line endings, then so must your git tree.  So you must not tell git to
> convert things.

Makes sense.

-Steve

Re: Windows viruses in Debian email packages [from Misc Developer News (#44)]

[Steve Robbins]

On Friday, August 4, 2017 12:35:04 PM CDT Paul Wise wrote:

> Windows viruses in Debian email packages
> 
> 
>  Sometimes[6] upstreams of email related packages include live Windows
>  viruses/malware in their test corpus, either by accident or on purpose,
>  with or without removing infection/transmission mechanisms. Due to the
>  large amount of anti-spam and anti-malware services monitoring the
>  Internet, this can lead to debian.org mirrors getting flagged and
>  reducing the reputation of debian.org in those services as well as source
>  packages getting blocked by the content-scanning firewalls that some
>  networks operate. If your package is email related and includes a test
>  corpus, please scan it for viruses/malware.  [...]

The news item doesn't specify what to do after scanning, but the referenced 
bug requests removal of the offending material.  I can certainly support the 
goal of avoiding mirrors being flagged as malware distrubutors, so removal 
makes sense from this point of view.   

The news bit refers to "test corpus", so removal would presumably not change 
the output.  But I have to wonder: are there not cases where the malware is 
present for *training* a detection system?  If so, I would imagine removal 
could reduce the effectiveness of training.  So what alternative exists for 
this case (if it indeed is a case we need to worry about)?

Thanks,
-Steve


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

Has Copyright summarizing outlived its usefulness?

[Steve Robbins]

On Tuesday, November 28, 2017 9:00:10 AM CST Chris Lamb wrote:
> Hi,
> 
> Sorry for the rejection but "Copyright: See individual source files"
> unfortunatley does not meet the high standards we strive for within Debian.

That is odd.  It has been accepted for over 16 years.   What has changed?   

It is useful to me that the debian/copyright file contain the distribution 
license.  For a one-author package, it could even be convenient to describe 
the author and copyright.

But for a massive multi-author, multi-year work like Boost, there seems very 
little value in summarizing copyrights.  Boost has nearly 55000 files in the 
source distribution.  What could one possibly achieve by summarizing this?  
How would anyone even read and make sense of it?

Has copyright summarizing outlived its usefulness for large sources?  Why 
shouldn't we have some way to say "Copyright by the Boost authors"?

-Steve


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

Why do we list individual copyright holders?

[Steve Robbins]

On Wednesday, November 29, 2017 11:46:00 PM CST Steve Robbins wrote:
> On Tuesday, November 28, 2017 9:00:10 AM CST Chris Lamb wrote:
> > Hi,
> > 
> > Sorry for the rejection but "Copyright: See individual source files"
> > unfortunatley does not meet the high standards we strive for within
> > Debian.
> 
> That is odd.  It has been accepted for over 16 years.   What has changed?

[...]

> Why shouldn't we have some way to say "Copyright by the Boost authors"?

It was pointed out [1] that the linux-image copyright file contains 
"Copyright: 1991-2012 Linus Torvalds and many others".  

So: if I changed the boost copyright file to say "Copyright: $Dates Boost 
authors", would it pass ftp-master scrutiny?

Thanks,
-Steve

[1] https://lists.debian.org/debian-devel/2016/08/msg00181.html






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

Re: Has Copyright summarizing outlived its usefulness?

[Steve Robbins]

On Thursday, November 30, 2017 11:26:31 AM CST Simon McVittie wrote:
> On Wed, 29 Nov 2017 at 23:46:00 -0600, Steve Robbins wrote:
> > On Tuesday, November 28, 2017 9:00:10 AM CST Chris Lamb wrote:
> > > Hi,
> > > 
> > > Sorry for the rejection but "Copyright: See individual source files"
> > > unfortunatley does not meet the high standards we strive for within
> > > Debian.
> > 
> > [For] a massive multi-author, multi-year work like Boost, there seems very
> > little value in summarizing copyrights.  Boost has nearly 55000 files in
> > the source distribution.  What could one possibly achieve by summarizing
> > this? How would anyone even read and make sense of it?
> 
> I've written about this before, for example in
> <https://lists.debian.org/debian-devel/2016/08/msg00181.html>, and I'd be
> very glad to see an "official" response from the ftp team.

It would, indeed, be nice to get a rationale for summarizing a file-by-file 
list of copyrights.

I re-read that 2016 thread just now and it seems to me that most of the 
discussion centres around summarizing the LICENSE(s) of the resulting work.  I 
agree that knowing the license of a package is useful.  Having 55000 copyright 
lines is not.

Perhaps we should deprecate debian/copyright and just create debian/license 
instead!

> For a large package, gathering the list of copyright holders from
> the source into debian/copyright is clearly a lot of work. Is there a
> rationale for why we do that work? Is it self-imposed (because there
> is believed to be consensus within Debian that we want it), or is it
> to comply with the requirements of that particular package's copyright
> license, or is it to meet some other legal requirement?

It's telling to me that there was *no* answer to your question in the 2016 
thread.  I have only been around Debian for 20 years.  Maybe someone with a 
longer history can recall the reasoning behind the copyright file?

-Steve


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

Re: Has Copyright summarizing outlived its usefulness?

[Steve Robbins]

Hi Ian,

As a preface to my comments: I am *only* complaining about collecting 
copyright notices.  I agree that collecting together a comprehensive license 
statement(s) is necessary.  The caveats of Russ Alberry [1] aside, these are 
two distinct tasks in my eyes.

[1] https://lists.debian.org/debian-devel/2017/12/msg00198.html


On Thursday, December 7, 2017 5:28:12 PM CST Ian Jackson wrote:

> And of course the per-contributor
> notices information is sometimes required, 

I guess that you're referring to the kind of license grants that Russ 
identified?  If that's in the license, then yes: we are bound by it.

However, that is NOT the case for a large number of licenses and is 
specifically NOT the case for Boost -- which is what started my complaint.  In 
these cases, I am still waiting for a cogent explanation of what purpose this 
serves.  In my experience, it wastes my time and likely that of FTP Masters.   

--

The frustration is compounded by the fact that overworked FTP-masters leave a 
NEW upload pending for 4 weeks then reject it based on a new interpretation of 
Debian Policy.  This is demotivating, I have to say.  The debian/copyright 
file contained the offending phrase for YEARS, and linux kernel copyright 
continues to have a similar collective copyright notice.  I'm sure there are 
others.  

It's a shame the FTP masters are not participating in the discussion.  
However, the consensus voiced in this thread (as was the case of the same in 
2016) is that while license summarizing (which can include, if the license has 
language such as Russ identified, also listing copyrights) is valuable, 
nothing has been said in favour of copyright summarizing.   

So I wonder what is the best way forward?  Should we amend the Policy Manual, 
striking out "copyright information" from the requirement "Every package must 
be accompanied by a verbatim copy of its copyright information and 
distribution license in the file /usr/share/doc/package/copyright. "  ?

Thanks,
-Steve


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

Re: Has Copyright summarizing outlived its usefulness?

[Steve Robbins]

On Sunday, December 10, 2017 8:09:16 PM CST Chris Lamb wrote:

> However, I just wanted to add that whilst I can understand the frustration
> of your package being rejected after spending some time in NEW, it would
> be unfair to characterise that as "leaving" or neglecting it. Attributing
> malice to the delay would indeed be demotivating… The queue is simply
> large right now and we are working through it.

Agreed.  I apologize my choice of words.  I did not mean to imply that it was 
left due to neglect.  I know it is due to a large queue.  

-Steve


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

Re: Has Copyright summarizing outlived its usefulness?

[Steve Robbins]

On Sunday, December 10, 2017 8:09:16 PM CST Chris Lamb wrote:

> I would also point out that regardless of the merits of some particular
> interpretation, if a perceived violation of it was potentially discovered,
> it does not seem a terribly logical defense that "it is been like that
> for some time." (So what? :p)

That is one interpretation of what I wrote.  

However: what I intended to convey is my perception that there was an 
unannounced shift of policy -- or a shift in interpretation-of-policy.  Being 
unannounced, I have no direct evidence for such a shift, of course.  So all I 
can present is that it was accepted for a long time and then suddenly not 
accepted.

-Steve


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

Re: Has Copyright summarizing outlived its usefulness?

[Steve Robbins]

On Sunday, December 10, 2017 11:11:20 PM CST gregor herrmann wrote:
> On Sun, 10 Dec 2017 12:44:52 -0600, Steve Robbins wrote:
> > However, the consensus voiced in this thread (as was the case of the same
> > in 2016) is that while license summarizing (which can include, if the
> > license has language such as Russ identified, also listing copyrights) is
> > valuable, nothing has been said in favour of copyright summarizing.
> 
> My understanding is that a license without any information who puts
> the software under this license (i.e. who is the copyright holder who
> can grant these rights) is incomplete.

OK, but surely it is up to Debian to choose the form of such information.  For 
instance: each binary package is unambiguously linked to a source package; 
said source package is easy to locate and contains the complete copyright 
holder information.

In the medical device industry, regulators allow vendors to use the "least 
burdensome" means of complying with a given regulation.  At the risk of 
sounding naive, why can't apply this principle to copyright?

-Steve


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

Re: Has Copyright summarizing outlived its usefulness?

[Steve Robbins]

Ben Finney  writes:
> Simon McVittie  writes:
> > On Wed, 13 Dec 2017 at 23:10:51 +1100, Ben Finney wrote:
> > > expecting to find “complete copyright holder information” such
> > > that we can be confident it *is* complete, solely in the upstream source
> > > is a folly, in my experience.
> > 
> > Given that, on what basis can a user of the package gain value from
> > our claim that the complete list of copyright holders is present in
> > debian/copyright?
> 
> Because that file is typically a record of a specific effort to
> *acquire* that information, and to document it for people who are
> careful about the provenance and grant of license in the work.

That description doesn't match my experience.  Nor does it match what the 
Policy Manual requests: "Every package must be accompanied by a verbatim copy 
of its copyright information and distribution license".

I have a very hard time believing that debian/copyright "typically" contains 
anything other than a scraping of upstream source files.  I take the existence 
of various tools to semi-automate this task as evidence in support of my 
thesis.  


> The distinction I'm drawing is in response to proposals in this thread,
> to declare the record in ‘debian/copyright’ to be obsolete. Some
> proposals have advocated that we rely on finding that information solely
> in the upstream work.

I'm advocating it because in practice that's what is happening -- it is a 
"verbatim copy of ... copyright information".  However, it's not worth my time 
to collate that from 55000 files.   The source package has the verbatim copy 
already ... we just need to point to it!
 

> > Linux distributions exist, they don't attempt to list every copyright
> > holder on the Linux kernel, and in practice this is fine, which
> > suggests that this is an ocean we're trying to boil as a weird Debian
> > thing rather than because we actually need to. It's fine to have weird
> > Debian things that we do because we're Debian rather than because we
> > absolutely need to do them - but when we do, we should be clear about
> > why, so that we can stop enforcing them if the cost (mostly in
> > maintainer time and motivation, our most valuable commodities) exceeds
> > the benefit.
> 
> I agree with the need to be clear about why. I hope this and other
> expressions in this thread have helped make it clearer.

Your email sounds like a personal preference of yours -- which is fine.  But 
it does not explain why Debian should demand it.  On the contrary: your 
expectation goes way beyond Policy's "verbatim copy".

-Steve


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