Re: Bug#747070: ITP: apt-venv -- apt virtual environment

2014-05-06 Thread Leo Iannacone 
On 6 May 2014 03:06, Paul Wise  wrote:
> chdist also sets APT_CONFIG, it doesn't however run bash but it would
> be trivial to add that.

I would like to do it by myself, but, as I already said, I am not
familiar with perl.

These are the requirements apt-venv satisfies, It would be great if
also chdist did the same:

 * application must allow user to run his own scripts/command
 * application must allow user to exec a bash session
   + application must prevent user from using sudo/su during a session
   + application must set env variable which points out the current
distro/release during session
 * application should support both Debian and Ubuntu
 * application should be compatible with XDG Base Directory Specification


Best,
L.

-- 
Ubuntu Member - http://launchpad.net/~l3on
Home Page - http://leoiannacone.com
GPG Key Id - 0xD282FC25


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/CACzqv1eu83ynZiw_rg6bp=fudkdphybhqujz6fqe_pmwhft...@mail.gmail.com

Ghostscript licensing changed to AGPL

2014-05-06 Thread Jonas Smedegaard 
Ghostscript have changed its license from GPL-3+ to AGPL-3+ since 
version 9.07.

Ghostscript includes a library - libgs9 - licensed as AGPL-3+ like the 
rest of the project.  It also includes a set of Type1 fonts apparently¹
licensed the same.

I've tried² suggest relicensing of the library part, mentioning the the 
problems AGPL has for libraries and fonts, and referring to our recent 
thread here.  Seems they have no interest in such change - or perhaps I 
simply failed in getting the message across - perhaps others here can 
help explain them the problems better than me.

Seems that these projects may link against Ghostscript, and therefore 
(possibly) effectively becomes AGPL-3+ with this change:

  * gimp
  * texlive-bin (texlive-binaries)
  * libspectre (libspectre1)
* cantor
* evas-loaders (libevas-loaders)
  * efl (libevas1, libecore-evas1, libecore-imf1, libecore-input1, 
libedje-bin, libedje1, libemotion1, libethumb-client1, 
libethumb1, libevas1-engine-fb, libevas1-engines-core, 
libevas1-engines-x)
* e17
* exactimage (edisplay)
* enna
* intone
* edbus (libedbus1)
  * elementary (libelementary1, libelementary-bin)
* python-edbus
  * libphone-ui-shr
* phoneuid
* evince (libevdocument3-4, evince, gir1.2-evince-3.0, libevview3-3, 
  evince-gtk)
  * denemo
  * gnome-documents
  * gnome-sushi
  * sugar-browse-activity
  * okular
  * qpdfview-ps-plugin
  * zathura-ps
  * gle-graphics

AGPL Ghostscript is now in experimental.  How to proceed?


 - Jonas


¹ Font license: http://bugs.ghostscript.com/show_bug.cgi?id=695210

² AGPL library: http://bugs.ghostscript.com/show_bug.cgi?id=695212

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: signature

Re: Gerrit patch review, and gating (was: Call for help from KDE Team)

2014-05-06 Thread David Goodenough 
On Tuesday 06 May 2014 11:03:07 Thomas Goirand wrote:
> On 05/02/2014 06:17 PM, David Goodenough wrote:
> > On Friday 02 May 2014 11:32:41 Maximiliano Curia wrote:
> >> ¡Hola Paul!
> >> 
> >> El 2014-05-02 a las 08:40 +0800, Paul Wise escribió:
> >>> On Fri, May 2, 2014 at 2:19 AM, Maximiliano Curia wrote:
>  For quite a while now the KDE team has been severely understaffed. We
>  maintain a lot of packages, with many different kinds of bugs, but we
>  don't have enough people to do all the work that needs to be done. We
>  have tools that help us automate the update to new upstream releases,
>  but that's just the tip of the iceberg of our work and so we are
>  writing to invite more people to get involved in the team and help us
>  get KDE software in Debian into better shape.>
> >>> 
> >>> Have you invited the Kubuntu team to join you? I'll send a mail to the
> >>> other derivatives I can find that use KDE.
> >> 
> >> We've invited the Kubuntu team to merge their efforts with ours and use
> >> the
> >> same packaging vcs. The answer was positive, although the migration is a
> >> bit too far in the future. They sort of agree that they could migrate
> >> from launchpad bzr to git.debian.org, but as they are a larger group
> >> they separate junior and senior developers, requiring a review for each
> >> junior commit, for which they have a workflow and systems in place that
> >> won't be directly usable in git.debian.org. so the idea is to keep in
> >> sync most of our work, and see if we can figure out a way to merge it.
> >> 
> >> Which translates to some overhead and a larger TODO list than an
> >> immediate
> >> help, but sure, once certain threshold in time invested is reached, both
> >> Debian and Ubuntu could benefit from it.
> >> 
> >> Happy hacking,
> > 
> > Sounds like a job for Gerrit.  Currently not fully packages for Debian
> > but I understand there is work being done one it.  There is a github
> > project at https://github.com/dnaeon/gerrit-debian which builds debs.
> > 
> > David
> 
> Someone starting a Debian package is a good idea, though IMO, it'd be
> nicer if gerrit could be properly packaged in Sid / Testing. Does anyone
> want to work on that? The above Debian package doesn't seem good after a
> quick look (for example, it build-depends on java6-runtime-headless
> which isn't in Sid anymore, depends on git-core instead of git,
> copyright file isn't right, etc.). If hands are raising for packaging
> gerrit and the necessary tools for building a gate, then I'd be happy to
> work on that as well (though I feel like I've got enough work with the
> packaging of OpenStack already, so my time would be unfortunately
> limited...).
> 
> I've seen that the DSA are currently building an OpenStack cloud (using
> the new Icehouse packages). I'm not sure what will be its use, or what's
> the current plan, though it'd be a super nice idea to use it to setup
> Gerrit and some kinds of gating process (piuparts & adequate comes to
> mind of course). This could be for example used for spawning VMs to do
> some checkings of each git commit on Alioth, with Gerrit as a tool for a
> patch review process.
> 
> Cheers,
> 
> Thomas Goirand (zigo)
There was talk of packaging Gerrit on the java list some while ago, but
it seems to have died.  Perhaps it would be worth asking there.  There were
some pre-reqs missing at the time so it may that some or all have now been
packaged and gerrit work just needs restarting.

David


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/10146786.YsFn2Urkpr@stargate

Re: Re: standalone logind (Re: Bits from the systemd + GNOME sprint)

2014-05-06 Thread Fabian Greffrath 
> > Sorry, but I suspect the latter.
> 
> Why did I expect any reasonable and balanced discussion!

Ever read you own "signature"?


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/1399373091.9982.7.ca...@kff50.ghi.rwth-aachen.de

fixed_versions format in the BTS and forcemerge

2014-05-06 Thread Vincent Lefevre 
I could see in a mail from control@b.d.o:

[...]
After four attempts, the following changes were unable to be made:
fixed_versions of #731426 is 'systemd/204-9' not '204-9'
fixed_versions of #726763 is 'systemd/204-9' not '204-9'
Failed to forcibly merge 729576: Unable to modify bugs so they could be merged.

But according to

  http://www.debian.org/Bugs/server-control.en.html#fixed

these are two correct, equivalent ways to mark a bug as fixed in
some version.

Shouldn't the format be fixed (i.e. either source_package/version
or just version)?

Or shouldn't the BTS detect that and allow the forcemerge after
possible conversion?

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140506153745.ga19...@ypig.lip.ens-lyon.fr

Bug#747235: RFP: tracebox -- Middlebox Detection Tool

2014-05-06 Thread Axel Beckert 
Package: wnpp
Severity: wishlist

* Package name: tracebox
  Version : 0.1
  Upstream Author : Gregory Detal  et al.
* URL or Web page : http://www.tracebox.org/
* License : GPLv2+
  Description : Middlebox Detection Tool

Tracebox is a tool that allows to detect middleboxes on any paths, i.e.,
between a source and any destination. Tracebox can be viewed as a tool
similar to traceroute as it uses ICMP replies to identify changes in the
packets. The fact that tracebox is able to detect middleboxes comes from
the observation that ICMP messages are often not as defined in
RFC792. Indeed it is quite common to receive a ICMP Time-to-Live
exceeded message with the original datagram instead of 64 bits as
described in the standard. This is caused by operating systems
configured to reply with full ICMP (e.g., Linux, Cisco IOS-XR, etc.) as
well as the ICMP Multi-Part Messages extension that standardize the fact
that routers using MPLS tunnels replies and ICMP message containing the
full datagram.

There seems a start of Debian packaging in the upstream repository, but
it's not complete (missing debian/copyright), and doesn't build a
working package, at least not when being used from a plain git checkout.

It seems that a prerequisite for packaging tracebox is packaging
libcrafter: https://github.com/pellegre/libcrafter -- it's included in
https://github.com/tracebox/tracebox as a git submodule.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87y4yelwll@kiva6.ethz.ch

Re: Ghostscript licensing changed to AGPL

2014-05-06 Thread Clint Adams 
On Tue, May 06, 2014 at 11:05:11AM +0200, Jonas Smedegaard wrote:
> AGPL Ghostscript is now in experimental.  How to proceed?

Upload to unstable since there's no actual problem?


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140506165126.ga2...@scru.org

Re: Ghostscript licensing changed to AGPL

2014-05-06 Thread Ian Jackson 
Jonas Smedegaard writes ("Ghostscript licensing changed to AGPL"):
...
> Seems that these projects may link against Ghostscript, and therefore 
> (possibly) effectively becomes AGPL-3+ with this change:

Thanks for looking into this and bringing it to our attention.

Do you know whether all those packages have licences which are
compatible with AGPL-3+ ?  If you're not sure then we (and I do mean
to include myself) should review them.

> AGPL Ghostscript is now in experimental.  How to proceed?

Personally I see no problem, provided all the licences are still
compatible.  If there are no incompatibility problems with the
rdepends, the AGPL version should go into unstable.

Ian.
(AGPL fan.)


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/21353.5276.749048.599...@chiark.greenend.org.uk

Re: fixed_versions format in the BTS and forcemerge

2014-05-06 Thread Don Armstrong 
Package: debbugs
Severity: normal
Control: retitle -1 -done messages with only a Version pseudoheader do not get 
turned into fully qualified verisons; see #729576.

On Tue, 06 May 2014, Vincent Lefevre wrote:
> I could see in a mail from control@b.d.o:
> 
> [...]
> After four attempts, the following changes were unable to be made:
> fixed_versions of #731426 is 'systemd/204-9' not '204-9'
> fixed_versions of #726763 is 'systemd/204-9' not '204-9'
> Failed to forcibly merge 729576: Unable to modify bugs so they could be 
> merged.
> 
> But according to
> 
>   http://www.debian.org/Bugs/server-control.en.html#fixed
> 
> these are two correct, equivalent ways to mark a bug as fixed in
> some version.
> 
> Shouldn't the format be fixed (i.e. either source_package/version or
> just version)?

The format is source_package/version; plain version is coerced into
source_package/version if version corresponds to a valid source package
version (or binary package version which corresponds to a valid source
package version).
 
> Or shouldn't the BTS detect that and allow the forcemerge after
> possible conversion?

Forcemerge tries to do the modification, but because #729576 is marked
as fixed in 204-9 instead of systemd/204-9, it fails. 

For safety, forcemerge won't try to modify the first bug given, so it's
going to fail.

The real issue here is that 204-9 should never have been just 204-9, but
should have been coerced into systemd/204-9; this is probably a bug in
-done handling which is exposed when you just give a Version
pseudoheader without a Source pseudoheader... and should be fixed.

-- 
Don Armstrong  http://www.donarmstrong.com

We have to face the fact that either all of us are going to die
together or we are going to learn to live together and if we are to
live together we have to talk. 
 -- Eleanor Roosevelt


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140506165257.gk7...@teltox.donarmstrong.com

Re: gnutls28 transition

2014-05-06 Thread Andreas Metzler 
Didier 'OdyX' Raboud  wrote:
> Le dimanche, 4 mai 2014, 02.14:17 peter green a écrit :
>> Personally I'd add a (build-)depends on the relicensed gmp in the next
>> gnutls28 upload. That way packages can (build-)depend on the new
>> gnutls and be assured of getting a GPLv2 compatible version.

Hello,

Afaiui it would be perfectly fine to /build/ GPLv2 code against older
GMP as long as we distribute the resulting binary only together with
the newer GMP binary. (The binary will often be identical, no matter
whether it is built against gmp 5.3 or 6).

Also I am reluctant with manually overriding gmp shlibs. How about
simply adding
Breaks: libgmp10 (<< 2:6)
to the libgnutls28 binary package?
[...]

> Dimitri John Ledkov wrote:
>> Should we start transition to gnutls28 by default, for all packages
>> that are compatible?

Due to size of the transition it is a little bit difficult, see

(Please keep this thread on d-d, -release is not a discussion list.)

I have done some test-builds and reported most of the issues I
found[1]. Some important library packages have already switched (cups,
curl), I guess the next one would be neon or gnome-vfs.

cu Andreas

[1]
https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=gnutls3;users=ametz...@debian.org

-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/bpvk3b-ep1@argenau.downhill.at.eu.org

Re: gnutls28 transition

2014-05-06 Thread Dimitri John Ledkov 
On 5 May 2014 18:53, Andreas Metzler  wrote:
> Didier 'OdyX' Raboud  wrote:
>> Le dimanche, 4 mai 2014, 02.14:17 peter green a écrit :
>>> Personally I'd add a (build-)depends on the relicensed gmp in the next
>>> gnutls28 upload. That way packages can (build-)depend on the new
>>> gnutls and be assured of getting a GPLv2 compatible version.
>
> Hello,
>
> Afaiui it would be perfectly fine to /build/ GPLv2 code against older
> GMP as long as we distribute the resulting binary only together with
> the newer GMP binary. (The binary will often be identical, no matter
> whether it is built against gmp 5.3 or 6).
>
> Also I am reluctant with manually overriding gmp shlibs. How about
> simply adding
> Breaks: libgmp10 (<< 2:6)
> to the libgnutls28 binary package?
> [...]
>

I was thinking that this would be indeed sufficient.


>> Dimitri John Ledkov wrote:
>>> Should we start transition to gnutls28 by default, for all packages
>>> that are compatible?
>
> Due to size of the transition it is a little bit difficult, see
> 
> (Please keep this thread on d-d, -release is not a discussion list.)
>
> I have done some test-builds and reported most of the issues I
> found[1]. Some important library packages have already switched (cups,
> curl), I guess the next one would be neon or gnome-vfs.
>

=/ i was hoping that it's api compatible, so we can't just blindly
take-over previous libgnutls-dev package name from gnutls28 sources
(like i've now proposed in the
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=747121 )

Are you talking about 3.2.13-2 or 3.3.1-1 from experimental or both
that things need fixing up to support?
Looking at the bugs it looks like either.


> cu Andreas
>
> [1]
> https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=gnutls3;users=ametz...@debian.org
>

-- 
Regards,

Dimitri.


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/CANBHLUiFME7FjKo2cpn4K4jQed2Ok4jsqZjcw3r=bX=j+xf...@mail.gmail.com

Re: standalone logind (Re: Bits from the systemd + GNOME sprint)

2014-05-06 Thread Matthias Urlichs 
Hi,

Kevin Chadwick:
> previously on this list Matthias Urlichs contributed:
> 
> > The second case is a no-brainer. Many packages in Debian consist of more
> > than one binary, of which you need at most one (if that). Do you really
> > want to mass-file a bug against all of these _and_ the packages depending
> > on them, or are you picking on systemd for non-technical reasons here?
> > 
> > Sorry, but I suspect the latter.
> 
> Why did I expect any reasonable and balanced discussion! I suspect
> but haven't mentioned that I expect the reasons for bundling these
> components together to be on highly questionable grounds.
> 
Oh, you mentioned that plainly enough.

A reasonable and balanced discussion may be started when somebody comes
forward with legitimate technical problems.  I did not perceive your
concerns as such.

* for better or worse, Debian decided on systemd as its future init system.
  As such it's probably going to be Priority: Standard, and Joe+Jane DD
  expect (IMHO entirely reasonably) that it's going to be all there.

* you didn't actually state what the TECHNICAL problem is. "I don't like
  it" is not a technical reason. "Another package will have problems
  replacing | turning off | not installing some part of systemd" is
  (respectively) true but not demonstrated to be relevant | false | not
  deemed relevant given the wide availability of multi-GByte microSD cards

* your signature has already been mentioned. If you state up front that
  you're not interested in a reasonable discussion, don't complain when it
  doesn't happen.

* last but not least: if you do have a tangible reason for your post, i.e.
  one of your packages doesn't work with the way systemd is packaged,
  kindly tell us which package that is and what you're trying to do.

  Otherwise this is all hypothetical, and while I cannot speak for others,
  I am sick and tired of discussing hypothetical things and will now go
  package the next version of python-yapps2. I suggest that you do
  likewise, with one of yours.

> I guess there is no unlaborious way to see which programs depend on a
> particular binary of a given package?
> 
The people packaging systemd probably (I do not speak for them) did not see
any good reason to split up these packages, for the reasons I mentioned in
this and my last email. If this is a real problem for you, kindly speak up
and tell us why disabling logind with two quick systemctl commands,
assuming that you _really_ do not need it, is insufficient.

-- 
-- Matthias Urlichs


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140506175146.ga12...@smurf.noris.de

Re: Non-source Javascript files in upstream source

2014-05-06 Thread Wouter Verhelst 
Op zaterdag 26 april 2014 16:51:57 schreef Ben Finney:
> "Steve M. Robbins"  writes:
> > On April 25, 2014 11:02:29 PM Ben Finney wrote:
> > > We promise the source for everything any recipient downloads as 
part
> > > of Debian. If non-source files are distributed in Debian source
> > > packages, without a way to confidently guarantee the 
corresponding
> > > source is what's already available in Debian, then that is a
> > > definite impact on the freedom of Debian recipients: it threatens
> > > the freedom promises in the Social Contract.
> > 
> > That is certainly not a universally held view. Some of us [1] regard
> > random trash littering the source distribution -- but not used in
> > generating the actual software (binary distribution) -- as merely a
> > nuisance that can be tolerated.
> 
> If it's in the Debian source package, it is distributed as part of
> Debian.
> 
> If it's distributed as part of Debian, it is subject to the promises in
> the Debian Social Contract.
> 
> Those promises include the promise that anything in Debian has its
> source in Debian.

Yes. And while I agree that this is a problem for things like precompiled 
Windows binaries, I'm not so sure when it regards convenience copies of 
minified javascript libraries. After all, there are many other packages 
whose upstream source ships with convenience copies of other code, and 
we don't consider those to be problems.

If a package will work equally well when using the Debian-packaged version 
of a javascript library rather than using the shipped convenience copy of 
the said library (as proven by using a symlink and a dependency to the 
relevant file and package rather than shipping the convenience copy in 
the binary package), then the source requirements for all relevant code is 
satisfied; it's just that they're done so by another source package.

> > I have to say that this absolutist zeal in scrubbing the source
> > package grates on me for two reasons. FIrst, it introduces an
> > undocumented difference between upstream source and Debian 
source.
> 
> The difference should not be undocumented: the difference should be
> described in the package, and its rationale given. ‘README.source’ is a
> good place to document the difference.

No, that's not what README.source is meant for. This should document 
"weirdness" about the package build system as necessary for an NMU'er to 
figure out how the package works.

-- 
It is easy to love a country that is famous for chocolate and beer

  -- Barack Obama, speaking in Brussels, Belgium, 2014-03-26

Re: lintian "source-is-missing" for jquery -- was Re: Bug#744699: Frets On Fire bug report 744699

2014-05-06 Thread Wouter Verhelst 
Op vrijdag 25 april 2014 19:34:02 schreef Daniel Pocock:
> When FTP masters approve a package from NEW, they might well see 
that
> the js is not really in use - but somebody (upstream or maintainer)
> may change something after 6 months and the js does get used

That argument goes for just about any RC bug. By that reasoning, FTP 
masters should not accept any package because someone could 
introduce an RC bug somewhere down the line.

I have a bit more trust in the ability of my co-developers to DTRT than that. 
After all, it's not like it's easy to gain upload rights in Debian without 
knowing how Debian works...

-- 
It is easy to love a country that is famous for chocolate and beer

  -- Barack Obama, speaking in Brussels, Belgium, 2014-03-26

Re: Point 1 of Social Contract

2014-05-06 Thread Thorsten Glaser 
On Sun, 4 May 2014, Timo Weingärtner wrote:

> The installer already asks whether to enable non-free repositories. Perhaps 

This could get a loud warning, yes.

> the warning could be more verbose differentiating between open-source-but-non-
> free (GFDL etc.) and closed-source.

There is no difference, from a Debian PoV, between those.
Both in spirit and in repositories.

bye,
//mirabilos
-- 
«MyISAM tables -will- get corrupted eventually. This is a fact of life. »
“mysql is about as much database as ms access” – “MSSQL at least descends
from a database” “it's a rebranded SyBase” “MySQL however was born from a
flatfile and went downhill from there” – “at least jetDB doesn’t claim to
be a database”  ‣‣‣ Please, http://deb.li/mysql and MariaDB, finally die!


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/alpine.deb.2.10.1405061339500.13...@tglase.lan.tarent.de

Re: standalone logind (Re: Bits from the systemd + GNOME sprint)

2014-05-06 Thread Kevin Chadwick 
previously on this list Matthias Urlichs contributed:

> > > 
> > > Sorry, but I suspect the latter.
> > 
> > Why did I expect any reasonable and balanced discussion! I suspect
> > but haven't mentioned that I expect the reasons for bundling these
> > components together to be on highly questionable grounds.
> > 
> Oh, you mentioned that plainly enough.

Really why not quote then, you are an assuming liar and quote the only
contentless part of my email which was a reply to your original
assumption.

> 
> A reasonable and balanced discussion may be started when somebody comes
> forward with legitimate technical problems.  I did not perceive your
> concerns as such.
> 
> * for better or worse, Debian decided on systemd as its future init system.
>   As such it's probably going to be Priority: Standard, and Joe+Jane DD
>   expect (IMHO entirely reasonably) that it's going to be all there.
> 
> * you didn't actually state what the TECHNICAL problem is. "I don't like
>   it" is not a technical reason. "Another package will have problems
>   replacing | turning off | not installing some part of systemd" is
>   (respectively) true but not demonstrated to be relevant | false | not
>   deemed relevant given the wide availability of multi-GByte microSD cards
> 
> * your signature has already been mentioned. If you state up front that
>   you're not interested in a reasonable discussion, don't complain when it
>   doesn't happen.
> 

I stand by it absolutely. There is no bias there only a deeply
technically founded opinion. What has that got to do with being open
minded and balanced on a point by point technical basis. You are the
one being closed minded and dismissive.

> * last but not least: if you do have a tangible reason for your post, i.e.
>   one of your packages doesn't work with the way systemd is packaged,
>   kindly tell us which package that is and what you're trying to do.

My first mail stated it. Why do you question it. Look at all the tasks
mentioned in the logind man page some of which are unneeded and
complex and will have affects upon security. Removing logind when
apps expect it is potentially insecure too especially if many are like
you and will not test this possibility. I have avoided root ipv6
exploits due to similar scrutiny. I don't see how you only caring about
functionality and not security or correctness is any reasonable
response.


> 
> > I guess there is no unlaborious way to see which programs depend on a
> > particular binary of a given package?
> > 
> The people packaging systemd probably (I do not speak for them) did not see
> any good reason to split up these packages, for the reasons I mentioned in
> this and my last email.

Nothing you mentioned touched on that at all. What would best practice
be?

> If this is a real problem for you, kindly speak up
> and tell us why disabling logind with two quick systemctl commands,
> assuming that you _really_ do not need it, is insufficient.
> 

See above. Though I didn't know it could be disabled officially like
avahi-daemon so thanks for that. It is still important for an admin to
be able to quickly see what packages may have issues or how to avoid
any unexpected security issues as a result of packages expecting it to
be around.

-- 
___

"There are two ways of constructing a software design. One is to make
it so simple that there are OBVIOUSLY no deficiencies. And the other is
to make it so complicated that there are no OBVIOUS deficiencies"

Professor C. A. R. Hoare
The 1980 Turing award lecture
___
___


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/806463.34955...@smtp118.mail.ir2.yahoo.com

Re: Ghostscript licensing changed to AGPL

2014-05-06 Thread Philipp Kern 
On Tue, May 06, 2014 at 11:05:11AM +0200, Jonas Smedegaard wrote:
> Ghostscript have changed its license from GPL-3+ to AGPL-3+ since 
> version 9.07.

I guess given that GPL-3+ would've been a problem in itself already and
given that GPL-3 and AGPL-3 are compatible, that there can't be that
many problems left.

> Seems that these projects may link against Ghostscript, and therefore 
> (possibly) effectively becomes AGPL-3+ with this change:
> 
>   * gimp
>   * texlive-bin (texlive-binaries)
>   * libspectre (libspectre1)
> * cantor
> * evas-loaders (libevas-loaders)
>   * efl (libevas1, libecore-evas1, libecore-imf1, libecore-input1, 
> libedje-bin, libedje1, libemotion1, libethumb-client1, 
> libethumb1, libevas1-engine-fb, libevas1-engines-core, 
> libevas1-engines-x)
> * e17
> * exactimage (edisplay)
> * enna
> * intone
> * edbus (libedbus1)
>   * elementary (libelementary1, libelementary-bin)
> * python-edbus
>   * libphone-ui-shr
> * phoneuid
> * evince (libevdocument3-4, evince, gir1.2-evince-3.0, libevview3-3, 
>   evince-gtk)
>   * denemo
>   * gnome-documents
>   * gnome-sushi
>   * sugar-browse-activity
>   * okular
>   * qpdfview-ps-plugin
>   * zathura-ps
>   * gle-graphics

Does that mean that people calling one of these from a script or a web
service (e.g. invoices using texlive-bin) will need to adhere to the
AGPL as well?

Kind regards
Philipp Kern


signature.asc
Description: Digital signature

Updated mime-support to version 3.55.

2014-05-06 Thread Charles Plessy 
Dear all,

I have uploaded an update of mime-support, to version 3.55.  Among the most
visible changes:

 - update-mime does not automatically quote anymore “%s” when collecting the
   package-provided mailcap lines from /usr/lib/mime/package/.  This may
   reveal bugs with applications that did not follow RFC 1524 and expected
   the mailcap system to do the quoting.

 - The “view” command is removed.  It was using the alternative system to
   share /usr/bin/view with vim, while both commands had different purposes
   and semantics.

 - Update-mime will now issue warnings to stderr when encountering improper
   package-provided mailcap entries.

 - The conversion of FreeDesktop entries to mailcap entries has been polished.

 - run-mailcap will try to guess the media type of a file as a last ressort
   using the “file” command, if it is available.

 - run-mailcap now recognises non-ASCII alphanumeric characters, which prevents
   the use of the temporary file in most cases.  (This was annoying for users
   as for instance the program opening the file would not run from the file's
   directory anymore).

As a side note, I have not been very successful in convincing bug reporters to
submit new media types to the IANA before sumbitting them to the mime-support
package; the problem is that for legacy media types nobody feels to have enough
authority to do so.  Nevertheless, for freshly invented media types, I intend
to be strict.

You can see the full changelog below.

mime-support (3.55) unstable; urgency=low

  * Media types removed:

  92def2a application/x-font-woff   Closes: #727156
  c1797d2 application/x-md5 Closes: #720619
  fad5967 application/x-sha1Closes: #720619
  a71f2b0 text/x-vcard  Closes: #674670

  * Media types added:

  0d95409 application/font-sfnt
  0d95409 application/font-tdpfr
  0f12ec4 application/font-woff
  020388a application/gzip  Closes: #589991, 688872
  77eee72 application/oebps-package+xmlSee: #712054
  ae8262a application/x-font-pcfCloses: #727171
  020388a application/zlib  Closes: #589991, 688872
  a71f2b0 text/vcardCloses: #674670

  * Changed associations of file suffixes with media types:

  ae8262a application/x-font: removed pcf extensions.
  46df3ed application/vnd.visio: added vst vsw vss
  1a69660 application/x-ns-proxy-autoconfig: removed dat, Closes: #418564

  * Packaging:

  b016fe8 Remove “see” alternative for “view”.
  Thanks to Kevin Ryde , Closes: #623384, #458691
  c5b794b Removed obsolete removal of /usr/doc/mime-support.

  * update-mime:

  5448676 Accept file names with alphanumeric characters from the current
  locale.  Thanks to Tomás , Closes: #682900
  2a2243e Handle the “%c” (caption) field code from Desktop entry files.
  Thanks to Philipp Matthias Hahn , Closes: #745153
  c0e8e69 Handle the “%i” (icon) field code from Desktop entry files.
  5cf809c Stop quoting “%s” when building /etc/mailcap from the files in
  /usr/lib/mime/packages.
  Thanks to Peter Chubb , Closes: #747050
  f18b89f Warn when mailcap.order refers to packages that do not provide
  mailcap files.  Closes: #314952
  7b1947f Reject lines that do not start with a media type.  Closes: #384161
  This drops support for continuation lines in /usr/lib/mime/packages/.

  * run-mailcap:

  3c3b56c Redirect stdin to the tty when a mailcap entry says needsterminal.
  Thanks Kevin Ryde , Closes: #727173
  80a1bc7 Remove unreliable permission check. Closes: #691247 thanks to
  Martin Mares  and Kevin Ryde .
  e833a8a Stricter pattern for detection of manual pages.
  Thanks to Philipp Janda, LP: #1300484
  40f72a7 Force the use of a temporary alias for files containing a space in
  their name. Closes: #723708 thanks to Kevin Ryde .
  642d6a9 Remind of RFC 1524 in the “SEE ALSO” section of mailcap(5) man page.
  Closes: #634254
  dd293ec Run the “file“ command when extension does not tell the media type.
  Thanks to Reuben Thomas , Closes: #77985
  56dba74 Remove last-resort guesses of crontabs and man pages.

 -- Charles Plessy   Wed, 07 May 2014 07:03:23 +0900

- 
Charles Plessy
Tsurumi, Kanagawa, Japan


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140506231309.ga11...@falafel.plessy.net

Re: A question about patches for upstream

2014-05-06 Thread Matthias Klose 
Am 06.05.2014 03:05, schrieb Charles Plessy:
> Le Mon, May 05, 2014 at 08:56:48PM +0200, Bas Wijnen a écrit :
>>
>> I'm happy to see that there is consensus anyway that forwarding bugs upstream
>> is the task of the maintainer.
> 
> Hi all,
> 
> being a package maintainer, I am always uncomfortable when I have the
> impression that I am considered like a human patch-pushing machine that 
> extends
> the impact of mass-scale patch producers.  Luckily it is not happening often,
> but please let's take a point of view that is less patch-centric and more
> human-centric.

having more build dependencies exposes you to the risk that more things will
break when these build dependencies are upgraded.  you should be aware of this
as a package maintainer.  It very much depends on the upstream if a software is
developed with a specific set of specific versions in mind, or with standards in
mind.  consider this when filing an ITP.

> When the first mass rebuilds with GCC and porting issues came to Debian, I was
> very impressed.  Years later it became a routine and I sometimes feel that I 
> am
> pressed by a machine.  There is not much apparent coordination with the other
> distributions (not our derivatives) that also conduce such large screens.

This is wrong. And I would like you to better research such claims before
posting these as facts.

> Especially for the GCC updates, it sometimes happens that if I do nothing,
> Fedora will do the same screen, send patches Upstream and I will only have to
> package a new upstream release as usual.

Just imagine Fedora would have the same mindset ...

> Why don't we start to share the workload ?
> It seems to be a race condition with a lot of duplicated work.

maybe, but that's how distros work.  Fedora 21 builds with GCC 4.9 as the
default. Find out about their local patches and which ones are forwarded 
upstream.

we could wait with a new update for the toolchain and other components until
every upstream has adopted to it.  I think that would leave us a couple of years
behind.  And I already got answers like "why fix it, it builds in Debian".

> Not
> to mention when Upstream himself follows the evolution of the toolchain.

Really?  This is certainly not the majority, and even in Debian there are
package maintainers who refuse to look after build failures until the new
toolchain is the default.

Looking at the results of the last test rebuild [1], there are about half of the
build failures caused by Debian itself:

 - mismatches in symbols files.  This is a long standing issue, and
   I think it is wrong to include every exposed C++ symbol in the
   symbols file.  This is an issue to discuss with the dpkg maintainers,
   and then with packagers.  There are 35 ftbfs caused by this.

 - usage of -Werror in debian/rules.  If a package maintainer wants to
   be more holy than the pope, fine. But then he should be able to
   keep up with this spirit.

   Unfortunately there are a few upstreams as well setting -Werror
   as the default.

   This counts for 18 build failures.

Afaics, all other build failures are caused by more strict C++ requirements, the
porting guide might give you some hints [2].

Test failures may point to wrong code, either in the package or generated by the
toolchain, however the former is the more likely.  The perl issue is analysed,
the mysql issue is not, and I honestly don't care about issues like the one for 
0ad.


So, from my point of leaf packages with a lot of build-dependencies should only
be packaged in Debian iff both the upstream and the package maintainers can keep
up with the amount of ongoing changes.

  Matthias

[1]
https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=ftbfs-gcc-4.9;users=debian-...@lists.debian.org
[2] http://gcc.gnu.org/gcc-4.9/porting_to.html


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/53697458.2050...@debian.org

Re: A question about patches for upstream

2014-05-06 Thread Charles Plessy 
Hi Matthias,

your answer exemplifies very well what I mean with “pressed by the machine”…

I will reply on one point only.

Le Wed, May 07, 2014 at 01:46:32AM +0200, Matthias Klose a écrit :
> Am 06.05.2014 03:05, schrieb Charles Plessy:
> > 
> > When the first mass rebuilds with GCC and porting issues came to Debian, I 
> > was
> > very impressed.  Years later it became a routine and I sometimes feel that 
> > I am
> > pressed by a machine.  There is not much apparent coordination with the 
> > other
> > distributions (not our derivatives) that also conduce such large screens.
> 
> This is wrong. And I would like you to better research such claims before
> posting these as facts.

Please trust me that I do not intend to be derogatory, demotivating or
libelous.  In what I wrote, I made sure that the word “apparent“ is there, to
show that I am not implying that there is no coordination, nor even not enough
coordination.

This said, please consider if there would be a benefit that people in my
situation can see better the coordination that is already taking place.  I
would argue that by definition, something that nedds “better research” is not
as apparent as it could be.  I have not seen much reference to similar efforts
in other distributions in the emails sent on this list to announce mass
rebuilds.  If you were considering about being more verbose and write a bit
more about what is happening behind the curtain, I am sure that it would be
appreciated (at least by me).

Cheers,

-- 
Charles Plessy
Debian Med packaging team,
http://www.debian.org/devel/debian-med
Tsurumi, Kanagawa, Japan


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140507001955.gb11...@falafel.plessy.net

Re: standalone logind (Re: Bits from the systemd + GNOME sprint)

2014-05-06 Thread Matthias Urlichs 
Hi,

Kevin Chadwick:
> > * last but not least: if you do have a tangible reason for your post, i.e.
> >   one of your packages doesn't work with the way systemd is packaged,
> >   kindly tell us which package that is and what you're trying to do.
> 
> My first mail stated it.

Did not. See below.

> Why do you question it.

Because I do not share your opinion. 

> Look at all the tasks mentioned in the logind man page some of which are
> unneeded and complex and will have affects upon security.

… which are …?

Like systemd in general, I question your assertion that splitting
logind into separate programs has any effect other than needlessly
increasing complexity. Now you have at least two programs whose services
are necessary (or at least damn convenient) to have on a normal Debian
system; also, these might need to talk to each other, above everything else
they do -- so you get to debug two interacting asynchronous processes
instead of one single-threaded one.

Also: s/programs/packages/g s/talk to/depend on/
  s/asynchronous/interdependent/ s/single-threaded/standalone/.

Also, while you mentioned that it does unnecessary things, you did not
state which of these you consider unnecessary. Sorry, but, that's like
ranting about how that  or  spends too much money:
I may or may not agree with you -- but until you state specifically what
you'd like to see cut ("reduce the 'defense'/'clothes' butget" is not
specific enough, and neither was your statement), there can be no
meaningful discussion.

As I'd like to keep d-devel civil (and mostly-technical), I will stop here.

-- 
-- Matthias Urlichs


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140507000605.gb12...@smurf.noris.de

Bug #702005: Where can i get more attention on this?

2014-05-06 Thread Luis Alejandro Martínez Faneyth 
Hi everyone,
I'm a little worried about bug #702005 and the lack of attention it's getting.
This bug is marked as resolved, and indeed it has been resolved for jessie and 
sid, but not for wheezy. This bug breaks Python 2.7. Every person that tries to 
upgrade python2.7 and python2.7-minimal from version 2.7.3-6 to 2.7.3-6+deb7u2, 
is affected by this bug. We're talking about everybody who installed Wheezy 
7.{0,1,2,3,4} and tries to upgrade today.
This is affecting also every debian derivative based on stable, and is worth 
mentioning:
XBian: http://forum.xbian.org/post-21595.html#pid21595Aptosid: 
http://www.aptosid.com/index.php?name=PNphpBB2&file=viewtopic&t=2556Canaima 
(spanish): 
http://listas.canaima.softwarelibre.gob.ve/pipermail/soporte/2014-April/009621.html
Please, can someone upload the fix to wheezy also?
Or, how can i help?
Thanks,
--
Luis Alejandro Martínez FaneythBlog: http://huntingbears.com.veGithub: 
http://github.com/LuisAlejandroTwitter: http://twitter.com/LuisAlejandro
CODE IS POETRY

Re: Ghostscript licensing changed to AGPL

2014-05-06 Thread Jose Luis Rivas 
Hi Jonas,

On 06/05/14, 11:05am, Jonas Smedegaard wrote:
> Ghostscript have changed its license from GPL-3+ to AGPL-3+ since 
> version 9.07.
> 
> Ghostscript includes a library - libgs9 - licensed as AGPL-3+ like the 
> rest of the project.  It also includes a set of Type1 fonts apparently¹
> licensed the same.
> 
> I've tried² suggest relicensing of the library part, mentioning the the 
> problems AGPL has for libraries and fonts, and referring to our recent 
> thread here.  Seems they have no interest in such change - or perhaps I 
> simply failed in getting the message across - perhaps others here can 
> help explain them the problems better than me.

I saw it and I fail to see what exactly they want to achieve with this
change since AGPLv3 is for web apps. I see you exposed your position
very well but they didn't gave specifics on what they want to avoid with
this besides "protect against commercial use of GPL Ghostscript" which I
believe is bad enough in DFSG terms.
> 
> Seems that these projects may link against Ghostscript, and therefore 
> (possibly) effectively becomes AGPL-3+ with this change:
> 
>   * gimp
>   * texlive-bin (texlive-binaries)

Actually with this one is worst, since the LPPL is not compatible with
the GPL, lets not even talk about GPLv3 or AGPLv3 :-/

[snip]
> 
> AGPL Ghostscript is now in experimental.  How to proceed?

I think we should get some feedback from debian-legal before doing
anything. We need to be aware of their intention, how they plan to
proceed on their "protection against commercial use" of Ghostscript and
what are the implications for the currently linked applications.

Kind Regards.

-- 
Jose Luis Rivas | ghostbar
The Debian Project → 
GPG 3E7D 4267 AFD5 2407 2A37 20AC 38A0 AD5B CACA B118


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140507014416.ga2...@arya.ghostbar.co

Bug#747273: ITP: ruby-delayer -- Ruby library providing delay the processing

2014-05-06 Thread HIGUCHI Daisuke (VDR dai) 
Package: wnpp
Severity: wishlist
Owner: "HIGUCHI Daisuke (VDR dai)" 

* Package name: ruby-delayer
  Version : 0.0.2
  Upstream Author : Toshiaki Asai 
* URL : https://rubygems.org/gems/delayer
* License : Expat
  Programming Lang: Ruby
  Description : Ruby library providing delay the processing

 The delayer library allows you to delay any tasks.
 It is similar to priority-queue mechanism.

I am packaging ruby-delayer as it is a dependency of mikutter
for next major version.

The git-repository is to be found here: 
http://anonscm.debian.org/gitweb/?p=pkg-ruby-extras/ruby-delayer.git
-- 
Regards,
dai

GPG Fingerprint = 0B29 D88E 42E6 B765 B8D8 EA50 7839 619D D439 668E


signature.asc
Description: Digital signature

Removal of emacs23 from unstable/testing

2014-05-06 Thread Rob Browning 

If we can, I'd like to remove emacs23 from unstable/testing before the
freeze.  To make that possible, any relevant packages will need to
migrate to emacs24, or just include support for emacs24.

In a while, assuming there are no showstopping objections, I'll see
about filing the relevant bugs for the remaining work.

Thanks
-- 
Rob Browning
rlb @defaultvalue.org and @debian.org
GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A
GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87tx926zu4@trouble.defaultvalue.org