Re: Debian Stretch new user report (vs Linux Mint)

2017-11-30 Thread Paul Wise 
On Fri, Dec 1, 2017 at 1:36 AM, Arturo Borrero Gonzalez wrote:

> * no support for the wifi interface of the dekstop machine (this was
> expected, fixed by installing non-free package by hand, since no
> network)

It would have been best for him to download the ISO with non-free
firmware embedded, do you know how he made the decision to download
the ISO without non-free firmware?

> * no support for RW on NTFS drives, only RO. This wasn't fixed even by
> installing ntfs-3g [0].
> I didn't have the time to investigate the NTFS issue myself, sorry :-(

Sounds like you need to get him to file a bug against ntfs-3g and
against whichever meta-package or other component should be installing
ntfs-3g. For the latter, perhaps gnome-software/PackageKit needs some
sort of filesystem detector that installs relevant packages. I was in
the same position recently with the Apple HFS+ filesystem.

> Both issues together were enough for my friend to directly move to
> Linux Mint in both machines, which is not fine

That is a shame, since Linux Mint isn't exactly known for its security
support. I'd strongly suggest he move to Debian with cinnamon and
other Linux Mint apps.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: Automatic downloading of non-free software by stuff in main

2017-11-30 Thread Adam Borowski 
On Thu, Nov 30, 2017 at 01:52:18PM +, Ian Jackson wrote:
> Over the years, d-legal has discussed a number of packages which
> automatically download non-free software, under some circumstances.
> 
> The obvious example is web browsers with extension repositories
> containing both free and non-free software.
> 
> We have also recently discussed a media downloader/player which, when
> fed a particular kind of url, will offer to automatically download a
> proprietary binary-only protocol module to access the specified
> proprietary web service.
[...]
> I would like to establish a way to prevent this.  (There are even
> whole Debian derivatives who have as one of their primary goals,
> preventing this.

No, those derivatives are damage.  While their hearts are in the right
place, they cause data loss and security holes by at least making people on
Intel and AMD machines use known-buggy microcode.

Yeah, opaque encrypted microcode can be used to sneak in new backdoors,
but that doesn't make past bugs (and "oh, those foul hackers found one of
our backdoors, it was a honest bug, really!") any better.  At the very
least, you get new TLA-only backdoors while those fixed are usable by both
TLAs and any random punk.

Likewise, closed firmware for your wifi card is evil, but still strictly
better than the same code burned into ROM: you get some bug fixes, and can
go back to a past version.  Sweeping non-free code under the carpet doesn't
help in any way -- if you have to use it, it's better kept where you can
see it.

The biggest reason for me to avoid non-free code is that neither me nor
anyone among us can fix problems.  And those derivatives you're talking
about tend to reintroduce this problem for political reasons (GFDL with
invariants).

Even Debian is not without fault here: for example, the ftpmasters accept
such a blatantly non-free licence as AGPL[1] into main.

> I think the necessary new central technical component is a
> configuration somewhere, checked by programs with plugin download
> capability.
> 
> We should have a conversation about:
> 
>  * What user experience options should ideally be available
>  * How those options should be represented in configuration
>  * Bug severity for programs that do not respect the "only free
>stuff" setting.

I don't think any such extra infrastructure is needed: what we have already
works well, at most it could take some clarification in the Policy.  I
believe the model that's in place for apt is worth adopting for browsers,
media players and such.

That is:
* no new non-free code is ever installed without the user's consent
  ("new" defined at package granulation, allowing splits/etc)
* it's not even proposed unless the software detects that such non-free
  parts are actually needed
* once a piece of non-free code is installed, it should receive updates
  unless explicitly configured otherwise

The last part matters because of recent Chromium issues.  Of course, checks
for updates should be done in a way that minimizes privacy issues (which
Chromium's upstream loves to maximize), but defaulting to no updates at all
is irresponsible.


Meow!

[1]. AGPL fails FSF freedom 0: you can't reuse snippets of code from an
AGPLed project in anything networked that has no, or cumbersome, ways to
pass advertising statements to the user (such as, eg, an IMAP server).
It also fails the Dissident Test: take a blogging software with
steganographic features, that you provide hosting for, for two classes of
users: fellow dissidents, and public at large.  The former receive the code
(both binaries and source), the latter do not.  Even revealing the existence
of your changes is a serious risk for the life of you and your friends.
Regular GPL has no such problems.

You might read my words as a sort of FSF bashing, as both bad licenses are
provided by them (GFDL and AGPL3), but regular GPL is generally much better
than BSD/MIT: it emulates a world without copyright much better, as in such
a world we'd have decompilers, etc.
-- 
< darkling> When all you have is a hammock, every problem looks like a nap.

Re: seccomp jailing for applications

2017-11-30 Thread Russ Allbery 
Seth Arnold  writes:
> On Fri, Dec 01, 2017 at 01:29:44AM +, Colin Watson wrote:

>> but should be much easier to maintain, and would probably also make it
>> easier to switch to a syscall-set-confining library if such a thing
>> exists in the future.

> Would a version of OpenBSD's pledge() system call have looked appealing to
> you, if it were implemented as a library interface around seccomp? There's
> already roughly two dozen categories, though not all may translate well to
> seccomp's abilities.

> https://man.openbsd.org/pledge.2

It's certainly better than listing system calls individually, so it would
be useful!

I think whether this or systemd's groupings are more useful depends
somewhat on the use case.  At a quick glance, I think I would more often
prefer systemd's approach to OpenBSD's (the groupings seem more useful),
but there are a few places where I could see it going the other way, and
there are places where OpenBSD is usefully more granular.

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

Re: seccomp jailing for applications

2017-11-30 Thread Russ Allbery 
Colin Watson  writes:
> On Fri, Dec 01, 2017 at 12:35:06AM +, Colin Watson wrote:

>> (Hmm, though maybe a reasonable stopgap would be to copy the relevant
>> syscall lists from systemd's code.  That would leave me updating things
>> manually from time to time, which isn't great, but it would probably
>> still be better than maintaining my own list!  I think I'll do this.)

> That was indeed a worthwhile exercise.  I'm now down to five sets taken
> verbatim from systemd, which are long but I can just update them
> wholesale from time to time; three sets from systemd from which I've
> extracted subsets, e.g. a read-only subset of file system operations;
> and nine additional syscalls, some of which I still need to review and
> possibly either restrict by arguments or drop.  Those are much more
> tolerable numbers than a monolithic block of over a hundred syscalls.

> The exercise caused me to notice several syscalls I'd missed, and some
> that I'd included inappropriately.  It's still a lot of lines of code,
> but should be much easier to maintain, and would probably also make it
> easier to switch to a syscall-set-confining library if such a thing
> exists in the future.

I have seriously considered writing an automated tool to do exactly that.
systemd has the right idea for UI for how to do reasonable seccomp
filters, but there's absolutely no reason why that maintained syscall list
needs to be systemd-internal code.  Thankfully, it should be pretty easy
to extract on an automated basis and publish in some sort of derived
library until such time as there's some lower-level library that does
this.  (Disclaimer: I've never asked systemd folks to publish it
separately, and am not familiar with any previous conversations about
this.)

Thank you so much for building seccomp jailing into man-db directly!  I
think this is an excellent step for anyone writing code for Linux systems
to consider doing these days.

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

Re: seccomp jailing for applications (was: recommends for apparmor in newest linux-image-4.13)

2017-11-30 Thread Seth Arnold 
On Fri, Dec 01, 2017 at 01:29:44AM +, Colin Watson wrote:
> but should be much easier to maintain, and would probably also make it
> easier to switch to a syscall-set-confining library if such a thing
> exists in the future.

Would a version of OpenBSD's pledge() system call have looked appealing to
you, if it were implemented as a library interface around seccomp? There's
already roughly two dozen categories, though not all may translate well to
seccomp's abilities.

https://man.openbsd.org/pledge.2

Thanks


signature.asc
Description: PGP signature

Re: seccomp jailing for applications (was: recommends for apparmor in newest linux-image-4.13)

2017-11-30 Thread Colin Watson 
On Fri, Dec 01, 2017 at 12:35:06AM +, Colin Watson wrote:
> (Hmm, though maybe a reasonable stopgap would be to copy the relevant
> syscall lists from systemd's code.  That would leave me updating things
> manually from time to time, which isn't great, but it would probably
> still be better than maintaining my own list!  I think I'll do this.)

That was indeed a worthwhile exercise.  I'm now down to five sets taken
verbatim from systemd, which are long but I can just update them
wholesale from time to time; three sets from systemd from which I've
extracted subsets, e.g. a read-only subset of file system operations;
and nine additional syscalls, some of which I still need to review and
possibly either restrict by arguments or drop.  Those are much more
tolerable numbers than a monolithic block of over a hundred syscalls.

The exercise caused me to notice several syscalls I'd missed, and some
that I'd included inappropriately.  It's still a lot of lines of code,
but should be much easier to maintain, and would probably also make it
easier to switch to a syscall-set-confining library if such a thing
exists in the future.

(Side note: this strategy works partly because man-db is under a licence
that the relevant file in systemd can be converted to using LGPL2.1
section 3.  If that weren't the case then it would at the very least be
much less obvious that this is a permissible thing to do.)

-- 
Colin Watson   [cjwat...@debian.org]

Work-needing packages report for Dec 1, 2017

2017-11-30 Thread wnpp 
The following is a listing of packages for which help has been requested
through the WNPP (Work-Needing and Prospective Packages) system in the
last week.

Total number of orphaned packages: 1179 (new: 7)
Total number of packages offered up for adoption: 148 (new: 1)
Total number of packages requested help for: 48 (new: 0)

Please refer to http://www.debian.org/devel/wnpp/ for more information.



The following packages have been orphaned:

   nixstatsagent (#882683), orphaned 5 days ago
 Description: NixStats agent
 Installations reported by Popcon: 2
 Bug Report URL: http://bugs.debian.org/882683

   pidgin-nateon (#882973), orphaned 2 days ago
 Description: Pidgin plugin for NateOn instant messaging service
 Reverse Depends: pidgin-nateon-dbg
 Installations reported by Popcon: 84
 Bug Report URL: http://bugs.debian.org/882973

   python-activipy (#882871), orphaned 3 days ago
 Description: implementation of ActivityStreams 2.0
 Installations reported by Popcon: 2
 Bug Report URL: http://bugs.debian.org/882871

   python-mpld3 (#882858), orphaned 3 days ago
 Description: D3 viewer for matplotlib
 Installations reported by Popcon: 67
 Bug Report URL: http://bugs.debian.org/882858

   python-mplexporter (#882857), orphaned 3 days ago
 Description: general matplotlib exporter
 Reverse Depends: python-mpld3 python3-mpld3
 Installations reported by Popcon: 75
 Bug Report URL: http://bugs.debian.org/882857

   python-odoorpc (#882870), orphaned 3 days ago
 Description: pilot Odoo servers through RPC
 Installations reported by Popcon: 5
 Bug Report URL: http://bugs.debian.org/882870

   python-oerplib (#882868), orphaned 3 days ago
 Description: Python client library to Odoo server
 Installations reported by Popcon: 11
 Bug Report URL: http://bugs.debian.org/882868

1172 older packages have been omitted from this listing, see
http://www.debian.org/devel/wnpp/orphaned for a complete list.



The following packages have been given up for adoption:

   rhythmbox-ampache (#882696), offered 5 days ago
 Description: play audio streams from an Ampache server
 Installations reported by Popcon: 44
 Bug Report URL: http://bugs.debian.org/882696

147 older packages have been omitted from this listing, see
http://www.debian.org/devel/wnpp/rfa_bypackage for a complete list.



For the following packages help is requested:

   autopkgtest (#846328), requested 365 days ago
 Description: automatic as-installed testing for Debian packages
 Reverse Depends: debci-worker openstack-pkg-tools
 Installations reported by Popcon: 1001
 Bug Report URL: http://bugs.debian.org/846328

   balsa (#642906), requested 2258 days ago
 Description: An e-mail client for GNOME
 Reverse Depends: balsa-dbg
 Installations reported by Popcon: 690
 Bug Report URL: http://bugs.debian.org/642906

   cargo (#860116), requested 233 days ago
 Description: Rust package manager
 Reverse Depends: dh-cargo
 Installations reported by Popcon: 526
 Bug Report URL: http://bugs.debian.org/860116

   cups (#532097), requested 3099 days ago
 Description: Common UNIX Printing System
 Reverse Depends: ayatana-indicator-printers bluez-cups boomaga
   chromium cinnamon-settings-daemon cloudprint cups cups-backend-bjnp
   cups-browsed cups-bsd (69 more omitted)
 Installations reported by Popcon: 180288
 Bug Report URL: http://bugs.debian.org/532097

   cyrus-sasl2 (#799864), requested 799 days ago
 Description: authentication abstraction library
 Reverse Depends: 389-ds-base 389-ds-base-libs 389-dsgw adcli
   autofs-ldap cairo-dock-mail-plug-in claws-mail
   claws-mail-acpi-notifier claws-mail-address-keeper
   claws-mail-archiver-plugin (121 more omitted)
 Installations reported by Popcon: 200961
 Bug Report URL: http://bugs.debian.org/799864

   dee (#831388), requested 503 days ago
 Description: model to synchronize mutiple instances over DBus
 Reverse Depends: dee-tools gir1.2-dee-1.0 libdee-1.0-4-dbg
   libdee-dev zeitgeist-core
 Installations reported by Popcon: 65317
 Bug Report URL: http://bugs.debian.org/831388

   developers-reference (#759995), requested 1188 days ago
 Description: guidelines and information for Debian developers
 Installations reported by Popcon: 15894
 Bug Report URL: http://bugs.debian.org/759995

   devscripts (#800413), requested 793 days ago
 Description: scripts to make the life of a Debian Package maintainer
   easier
 Reverse Depends: apt-build apt-listdifferences aptfs arriero
   brz-debian bzr-builddeb customdeb debci debian-builder debmake (26
   more omitted)
 Inst

Re: seccomp jailing for applications (was: recommends for apparmor in newest linux-image-4.13)

2017-11-30 Thread Colin Watson 
On Wed, Nov 29, 2017 at 05:36:30PM -0800, Russ Allbery wrote:
> Vincas Dargis  writes:
> > Since mentioned, I would like that these daemons would implement seccomp
> > filtering themselves, meaning like within application itself, using
> > libeseccomp. Thy can fine-grain what thread what syscalls can make.
[...]
> Does libeseccomp now have maintained system call classes similar to
> systemd?

(I think "libeseccomp" was a typo for "libseccomp".  I wouldn't normally
bother to point this out, but you reproduced it, and it caused me to
briefly get excited at the idea that maybe there was an "extended
seccomp" library or something.)

As far as I can tell, no.  I've been working on applying seccomp
confinement to parts of man-db recently (there are plenty of bits of its
code that could usefully be hardened against the admittedly small chance
of a compromise via crafted manual page text).  I have the self-imposed
spec of "should allow the process to do most reasonable things to
itself, to read and write data from and to already-open file
descriptors, to open files in read-only mode, and to fork new processes
with the same restrictions".  This results in a list of 116 syscalls at
last count, and it's hard to be certain that such a list is complete.
Since this is in application code rather than service code, systemd's
SystemCallFilter predefined sets aren't directly usable in this context;
I'd definitely like to use a library that provided something similar,
maybe a wrapper on top of libseccomp.

(Hmm, though maybe a reasonable stopgap would be to copy the relevant
syscall lists from systemd's code.  That would leave me updating things
manually from time to time, which isn't great, but it would probably
still be better than maintaining my own list!  I think I'll do this.)

-- 
Colin Watson   [cjwat...@debian.org]

Re: Auto-update for sid? Auto-backport?

2017-11-30 Thread Ian Jackson 
Adrian Bunk writes ("Re: Auto-update for sid? Auto-backport?"):
> Sometimes I see bug reports in the BTS where it is evident that a user 
> has spent hours or days on debugging an issue and writing a marvelous 
> bug report. I read the bug 10 years later with no other message ever
> in the bug.
> 
> That's sad to read, and a disservice to our users.

It's sad, indeed.  But is it a disservice ?

We didn't _make_ the user spend their time debugging it.  They
probably did that because the package was useful enough to them to
warrant it.  That user is probably better off with the package, even
in its unfortunate languishing state, than without it.

The same can go for other users, who probaby prefer a package in
Debian that they may have to apply a patch from the BTS to, to no
package at all.

Ian.

Debian Stretch new user report (vs Linux Mint)

2017-11-30 Thread Arturo Borrero Gonzalez 
Hi,

Please take this email as another call to keep the hard work in
improving our operating system and user experience, specially for new
users. Several times I've detected that we lack reports from final
users using our system, so here is another case.

Recently a friend of mine tried his first take at Linux in his
laptop/desktop. He tried Linux Mint in the laptop machine which worked
out of the box: wifi, external usb hardware, etc.
He then tried Debian Stretch in the desktop machine. He has been
sending me feedback of what happened, and the issues so far were:

* no support for the wifi interface of the dekstop machine (this was
expected, fixed by installing non-free package by hand, since no
network)
* no support for RW on NTFS drives, only RO. This wasn't fixed even by
installing ntfs-3g [0].

Both issues together were enough for my friend to directly move to
Linux Mint in both machines, which is not fine, but anyway he is now
using Linux since he didn't came back to Windows, which is great :-)

I didn't have the time to investigate the NTFS issue myself, sorry :-(

No debate intended, just information, a simple real-world case.
This was somehow an advanced user, enough for installing the operating
system by himself, but not enough to know the deep internals of
Debian/Linux.

best regards.

[0] https://wiki.debian.org/NTFS

Bug#883195: ITP: node-lexical-scope -- detect global and local lexical identifiers from javascript

2017-11-30 Thread Bastien ROUCARIES 
Package: wnpp
Severity: wishlist
Owner: ro...@debian.org
X-Debbugs-CC: debian-devel@lists.debian.org

* Package name: node-lexical-scope
  Version : 1.2.0
  Upstream Author : James Halliday  (http://substack.net)
* URL : https://github.com/substack/lexical-scope
* License : Expat
  Programming Lang: JavaScript
  Description :  detect global and local lexical identifiers from
javascript source code

This package detects wether  an indentifier is global scope or lexical scope.

 This a dependency of Browserify is a JavaScript tool that allows
 developers to write Node.js-style modules that compile for use in
 the browser.
 .
 Node.js is an event-based server-side JavaScript engine.

Re: Upload host down?

2017-11-30 Thread Dirk Eddelbuettel 

On 30 November 2017 at 07:38, Dirk Eddelbuettel wrote:
| 
| Hi all,
| 
| Just built R 3.4.3 which was released a few hours ago, but I can't push it
| via dput and dupload. Everything times out.
| 
| Is usper.debian.org down or unreachable?

Better now, and r-base_3.4.3 is being upload. Thanks to whoever fixed it, or
the internet gods.

(I was being paranoid because it so happens that Compast also flipped my
static-for-around-two-year-but-you-don't-pay-for-static-so-dynamic Ip last
night and I was worried they might be port blocking and what not.)

Dirk
 
| If a made a simple mistake of not catching a new upload mechanism, could
| someone kindly clue me in (maybe by private email reply?)
| 
| Thanks,  Dirk
| 
| -- 
| http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

-- 
http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

Re: Automatic downloading of non-free software by stuff in main

2017-11-30 Thread Andrey Rahmatullin 
On Thu, Nov 30, 2017 at 01:52:18PM +, Ian Jackson wrote:
> I would like to establish a way to prevent this. 
Why would the project do that, though?

> (There are even whole Debian derivatives who have as one of their
> primary goals, preventing this.
Good.

> We should aim for most of the changes necessary for
> such derivatives to be in Debian proper, so the derivative can be
> little more than a change to the default configuration.)
Why?

I also hope that you already have people who will do the actual work after
the discussions will provide the architecture.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Automatic downloading of non-free software by stuff in main

2017-11-30 Thread Ian Jackson 
This mail is going to a lot of lists.  I have set the followups to
d-policy because ultimately this is hopefully going to result in a
change to policy.


Over the years, d-legal has discussed a number of packages which
automatically download non-free software, under some circumstances.

The obvious example is web browsers with extension repositories
containing both free and non-free software.

We have also recently discussed a media downloader/player which, when
fed a particular kind of url, will offer to automatically download a
proprietary binary-only protocol module to access the specified
proprietary web service.

We have generally put software like this in main, because it asks the
user first, and can be used perfectly well without the proprietary
parts.  But the overall result is that a user who wants to use Free
software can be steered by Debian into installing and using non-free
software, sometimes unwittingly,

I would like to establish a way to prevent this.  (There are even
whole Debian derivatives who have as one of their primary goals,
preventing this.  We should aim for most of the changes necessary for
such derivatives to be in Debian proper, so the derivative can be
little more than a change to the default configuration.)

I think the necessary new central technical component is a
configuration somewhere, checked by programs with plugin download
capability.

We should have a conversation about:

 * What user experience options should ideally be available
 * How those options should be represented in configuration
 * Bug severity for programs that do not respect the "only free
   stuff" setting.

Ideally we can come up with a technical solution which means that it
is easy for existing programs implement the new check, so that failure
to do so can be RC for buster.

The minimum required changes to individual packages should be small.

NB that this is going to be a _user option_.  I'm not trying to shut
down non-free extension repositories.  (Indeed I sometimes use them.)
I want to give users more control.


Obviously excluded from this discussion are downloader packages, which
have the fetching and use of proprietary things as their primary
purpose, and which therefore live in contrib.


But there is another category I want to distinguish:

Applications for processing Turing-complete file formats.  This
includes web browsers, because of Javascript; but it also includes
PostScript viewers; interactive fiction interpreters; and so on.

The distinction between this and the general plugins I mention above
is that these applications all restrict the capabilities of the code
being executed, by running it in some kind of sandbox or container.
The idea being that the code gets to control the user's interactions
_with the providers of that code_, but not anything else.

There are some people who object to executing any non-free code on
their computer and I don't mind providing a facility for people to
restrict that.  But I don't know exactly how to design such a thing.

For web browsers, there is the FSF's libre-JS.  Personally I think
that is rather quixotic (and doesn't really address the real user
freedom question anyway), but I have no objection if anyone wants to
do the work to integrate that into some kind of freeness control
system.

But with file formats, the situation is much harder.  I don't feel we
can introduce a policy requirement requiring package maintainers to
support users who want this kind of restriction, until we can come up
with a scheme that will actually work and be useable (and indeed, will
be minimal effort for a package maintainer to opt into).

(The question is: how do we stop a Postscript file received by email
being rendered automatically when the user clicks on it, while
allowing the user to still open a Postscript file they generated
themselves ?)


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: Upload host down?

2017-11-30 Thread Pirate Praveen 
On വ്യാഴം 30 നവംബര്‍ 2017 07:08 വൈകു, Dirk Eddelbuettel wrote:
> 
> Hi all,
> 
> Just built R 3.4.3 which was released a few hours ago, but I can't push it
> via dput and dupload. Everything times out.
> 
> Is usper.debian.org down or unreachable?
> 
> If a made a simple mistake of not catching a new upload mechanism, could
> someone kindly clue me in (maybe by private email reply?)
> 
> Thanks,  Dirk
> 

from #debian-ftp,

zigo (IRC)
ftp.upload appears down to me, no worries, I uploaded to ftp-eu, just
wanted to tell, just in case...
J
jcristau (IRC)
seems we lost access to our metal at csail


I also uploaded to ftp-eu



signature.asc
Description: OpenPGP digital signature

Upload host down?

2017-11-30 Thread Dirk Eddelbuettel 

Hi all,

Just built R 3.4.3 which was released a few hours ago, but I can't push it
via dput and dupload. Everything times out.

Is usper.debian.org down or unreachable?

If a made a simple mistake of not catching a new upload mechanism, could
someone kindly clue me in (maybe by private email reply?)

Thanks,  Dirk

-- 
http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

Processed: Re: Bug#883134: general: Add new package header Upstream-Version:

2017-11-30 Thread Debian Bug Tracking System 
Processing control commands:

> tags -1 moreinfo
Bug #883134 [general] general: Add new package header Upstream-Version:
Bug #883133 [general] general: Add new package header Upstream-Version:
Added tag(s) moreinfo.
Added tag(s) moreinfo.

-- 
883133: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=883133
883134: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=883134
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#883134: general: Add new package header Upstream-Version:

2017-11-30 Thread Geert Stappers 
Control: tags -1 moreinfo

On Thu, Nov 30, 2017 at 04:25:54AM +0200, Victor Porton wrote:
> I am writing software which should call a program in specific version range
> (or fail to call it if the program in this version range is not installed).

Please elaborate the problem you want to solve.


Groeten
Geert Stappers
-- 
Leven en laten leven

Re: Has Copyright summarizing outlived its usefulness?

2017-11-30 Thread Simon McVittie 
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
, and I'd be
very glad to see an "official" response from the ftp team.

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?

As I said in the past, I am firmly of the opinion that whatever goals we
have for copyright files should be written down, and anything that isn't
necessary to achieve those goals shouldn't be required. If we enforce
some rules because they're the rules, that seems dangerously circular.

Even if the rationale turned out to be "the ftp team have received legal
advice saying that we have to do this, but we cannot publish that advice",
at least that way we'd know. This seems unlikely, though, because legal
entities with considerably more money than Debian (therefore a more
attractive target for lawsuits) are much, much less thorough about this
than we are.

adwaita-icon-theme is a convenient example of a package where following
what are apparently the rules[1] produces what I consider to be an
absurd result (an 88K copyright file naming 200 potential copyright
holders, not all of which are even legal entities but that didn't stop
them from being used in copyright notices, for a not particularly
large package). Doing the same for something actually large like
src:linux, src:perl or src:python3.6 would be worse (Perl's AUTHORS lists
more than 1200 names, Python's ACKS has over 1700), and IMO would make
their copyright files actively *less* useful by burying the most useful
parts under a list of hundreds or thousands of contributors. Whatever
goals the copyright file was meant to achieve, I'm not convinced this
is helping them...

Regards,
smcv

[1] I'll admit that some https://en.wikipedia.org/wiki/Work-to-rule might
have been involved in this case

Bug#883168: ITP: javabeans-activation-framework -- JavaBeans Activation Framework

2017-11-30 Thread Emmanuel Bourg 
Package: wnpp
Severity: wishlist
Owner: Emmanuel Bourg 

* Package name: javabeans-activation-framework
  Version : 1.2.0
  Upstream Author : Oracle
* URL : https://github.com/javaee/activation
* License : CDDL-1.1 or GPL-2 with Classpath exception
  Programming Lang: Java
  Description : JavaBeans Activation Framework

The JavaBeans Activation Framework (JAF) is a standard extension to the Java
platform that lets you take advantage of standard services to: determine the
type of an arbitrary piece of data; encapsulate access to it; discover the
operations available on it; and instantiate the appropriate bean to perform
the operation(s).

This API used to be a standard part of the JRE since Java 6, but starting
with Java 9 it's no longer available in the default classpath without a
special JVM parameter, and it's likely to be removed in a future version
of the JRE. Upstream projects depending on the activation framework,
typically through the JavaMail API, are now adding back this jar after
removing it a few years ago to ensure the compatibility with Java 9.

This package will be maintained by the Java Team.