Bug#734354: ITP: fonts-croscore -- width-compatible fonts for improved on-screen readability
Package: wnpp Severity: wishlist Owner: Fabian Greffrath * Package name: fonts-croscore Version : 1.23.0 * URL : http://gsdview.appspot.com/chromeos-localmirror/distfiles/ * License : Apache-2.0 Programming Lang: TTF Description : width-compatible fonts for improved on-screen readability This package contains a collections of fonts that offers improved on-screen readability characteristics and the pan-European WGL character set and solves the needs of developers looking for width-compatible fonts to address document portability across platforms. This package contains fonts that provide metric-compatible replacements for Arial, Courier New and Times New Roman and Symbol as shipped by Microsoft with its Windows operating systems. Its purpose is very similar to that of fonts- liberation, but the fonts have a wider glyph coverage and are licensed more liberally (as a matter of fact, fonts-liberation (>= 2.0.0) is based on these very fonts). I am going to package them under the scope of the pkg-fonts team alongside fonts-crosextra-caladea and fonts-crosextra-carlito, which provide metric-compatible replacements for Cambria and Calibri, respectively. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140106095300.18303.81563.report...@kff50.ghi.rwth-aachen.de
Re: GPLv2-only considered harmful
On Sun, 5 Jan 2014, Clint Adams wrote: > because any code under this license would be deliberately incompatible > with anything else FOR NO GOOD REASON. Uhm, then stop advocating the GNU GPL, which is deliberately incompatible with anything else FOR NO GOOD REASON. bye, //mirabilos -- [16:04:33] bkix: "veni vidi violini" [16:04:45] bkix: "ich kam, sah und vergeigte"... -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/alpine.deb.2.10.1401061102320.3...@tglase.lan.tarent.de
Re: Delegation for the Release Team
On Thu, Dec 26, 2013 at 01:23:42PM +0100, Lucas Nussbaum wrote: > > I'd like to note that the discussion on this delegation was inconclusive > on a couple of points: > > 1) it does not include anything about defining rules for NMU delays. > > The last time the NMU "policy" was changed was in 2011. The process used > back then was: > - the release team announced its intention to change the policy in > https://lists.debian.org/debian-devel-announce/2011/03/msg00016.html > - #625449 was filed against developers-reference > - there was some discussion > - the proposed change made it into developers-reference > > I believe that this was a very reasonable way to make such a change, and > that there is no need to give explicit authority to the release team over > the definition of the recommended delays for NMUs in developers-reference[1]. > [1] http://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#nmu > > Of course, if recommended NMU delays are discussed again in the future, > I think that the release team's opinion should be heard with great > attention, given the role of NMUs in achieving quicker bug fixing and, in > fine, faster releases. > Hi Lucas, This is somewhat troubling, as I pointed out in http://lists.alioth.debian.org/pipermail/dpl-helpers/2013-December/000124.html Explicitly again: Please see the last 7 years worth of bits mails, where the release team have lowered this without advance notice, for BSPs etc. As you have chosen to explicitly remove this role of the release team, without consensus, could you please state who you are now allowing to change NMU policy? Neil -- signature.asc Description: Digital signature
Re: Delegation for the Release Team
Hi, On 06/01/14 at 11:56 +, Neil McGovern wrote: > On Thu, Dec 26, 2013 at 01:23:42PM +0100, Lucas Nussbaum wrote: > > > > I'd like to note that the discussion on this delegation was inconclusive > > on a couple of points: > > > > 1) it does not include anything about defining rules for NMU delays. > > > > The last time the NMU "policy" was changed was in 2011. The process used > > back then was: > > - the release team announced its intention to change the policy in > > https://lists.debian.org/debian-devel-announce/2011/03/msg00016.html > > - #625449 was filed against developers-reference > > - there was some discussion > > - the proposed change made it into developers-reference > > > > I believe that this was a very reasonable way to make such a change, and > > that there is no need to give explicit authority to the release team over > > the definition of the recommended delays for NMUs in > > developers-reference[1]. > > [1] http://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#nmu > > > > Of course, if recommended NMU delays are discussed again in the future, > > I think that the release team's opinion should be heard with great > > attention, given the role of NMUs in achieving quicker bug fixing and, in > > fine, faster releases. > > > > Hi Lucas, > > This is somewhat troubling, as I pointed out in > http://lists.alioth.debian.org/pipermail/dpl-helpers/2013-December/000124.html > > Explicitly again: Please see the last 7 years worth of bits mails, where > the release team have lowered this without advance notice, for BSPs etc. > > As you have chosen to explicitly remove this role of the release team, > without consensus, could you please state who you are now allowing to > change NMU policy? First, I do not think that we have a NMU *policy*. What we have is a set of (non-binding) recommended procedures, including recommended delays, documented in developers-reference. The current content of dev-ref is mostly the result of DEP1[1,2], which I co-drove back in 2008. It was later modified to include the result of #625449[3] (0-day NMU for RC bugs with no activity for more than 7d). [1] http://anonscm.debian.org/viewvc/ddp/manuals/trunk/developers-reference/pkgs.dbk?r1=5249&r2=5353 [2] http://dep.debian.net/deps/dep1.html [3] http://anonscm.debian.org/viewvc/ddp/manuals/trunk/developers-reference/pkgs.dbk?r1=8702&r2=8902 I think that this part of developers-reference, like any part of dev-ref, can be changed by any DD, following a process similar to the one the release team used in 2011: > - the release team announced its intention to change the policy in > https://lists.debian.org/debian-devel-announce/2011/03/msg00016.html > - #625449 was filed against developers-reference > - there was some discussion > - the proposed change made it into developers-reference That is, propose a change and seek consensus. Also, I'd like to point out that, in fine, I don't think that the DPL has the power to decide on an NMU *policy*, and thus cannot delegate that power to the release team, because deciding on such policy would be a power of the TC, not the DPL. See Constitution 6.1.1: | The Technical Committee may: | | 1. Decide on any matter of technical policy. | | This includes the contents of the technical policy manuals, | developers' reference materials, example packages and the behaviour | of non-experimental package building tools. (In each case the usual | maintainer of the relevant software or documentation makes decisions | initially, however; see 6.3(5).) - Lucas signature.asc Description: Digital signature
Re: [DEP 8] About "XS-Testsuite: autopkgtest": time to remove "XS-" ?
Guillem Jover writes ("Re: [DEP 8] About "XS-Testsuite: autopkgtest": time to
remove "XS-" ?"):
> On Fri, 2014-01-03 at 19:40:54 +0100, Jakub Wilk wrote:
> > No, it just means that I gave up.
>
> Oh, ok. :/ Personally I see it has similar drawbacks to the discarded
> Build-Options field that some people wanted to use to list support for
> build-arch/build-indep targets, the difference here is, that I can see
> it also being useful so that autopkgtest implementations don't take over
> the debian/tests/control pathname as the sole owners, and alternative
> implementations could use that file with different deb822 contents, for
> example.
That proposal is an incompatible change to the existing DEP-8
specification, which does not require a DEP-8 test runner to check the
Testsuite field.
Having said that, I think the new field is a good idea to make it
easier for software to find packages with tests.
Also, a package might have two test suites, which would have to have
different filenames.
> So, I guess I'll just go ahead and add the two line patch needed to
> recognize the field for 1.17.6; queued now locally for my next push.
Thanks,
Ian.
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/21194.41867.663858.687...@chiark.greenend.org.uk
Re: 'tty' output on kFreeBSD, etc. within sbuild
Alastair McKinstry writes ("'tty' output on kFreeBSD, etc. within sbuild"):
> Can anyone answer the following question which is puzzling me;
> I have a piece of csh code which gets called during the build of a package
> i'm maintaining. it does the following:
>
> echo "useful information" > /dev/tty
>
> within the script. (stdout, stderr being redirected, I think).
Others have explained why you shouldn't do this.
If you want to bypass some redirection in the rest of your package's
build system, you could stash a copy of stderr in fd 3 or 5 or
something (eg, in the rules file, with 3>&2), and then write to fd 5.
But perhaps more information would enable us to give better advice.
Thanks,
Ian.
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/21194.41999.179696.729...@chiark.greenend.org.uk
Re: [RFH] [with fix] totally hosed init system
On Mon, 6 Jan 2014, Chow Loong Jin wrote:
> Upstart doesn't directly make use of the LSB headers -- it just calls back
> onto
Ah okay, thanks for this explanation!
(I’ve switched back to sysvinit for now.)
On Sat, 4 Jan 2014, Roger Leigh wrote:
> It might be safer to do something like this:
Indeed. Even worse, it has to be done repeatedly,
until insserv spews no more errors. Screen log:
root@tglase:/etc # mksh reinit
insserv: Service dbus has to be enabled to start service avahi
insserv: exiting now!
insserv: Service mountdevsubfs has to be enabled to start service bootlogd
insserv: exiting now!
insserv: Service hostname has to be enabled to start service bootlogs
insserv: exiting now!
insserv: Service checkroot has to be enabled to start service checkfs
insserv: exiting now!
insserv: Service checkroot has to be enabled to start service
checkroot-bootclean
insserv: exiting now!
insserv: Service mountdevsubfs has to be enabled to start service checkroot
insserv: Service hostname has to be enabled to start service checkroot
insserv: exiting now!
insserv: Service avahi-daemon has to be enabled to start service cups-browsed
insserv: exiting now!
insserv: Service sshd has to be enabled to start service freenx_server
insserv: exiting now!
insserv: Service mountdevsubfs has to be enabled to start service hdparm
insserv: exiting now!
insserv: Service mountdevsubfs has to be enabled to start service hwclock
insserv: exiting now!
insserv: Service mountkernfs has to be enabled to start service keyboard-setup
insserv: exiting now!
insserv: Service mountdevsubfs has to be enabled to start service lvm2
insserv: exiting now!
insserv: Service mdadm-raid has to be enabled to start service mdadm
insserv: exiting now!
insserv: Service mountkernfs has to be enabled to start service mdadm-raid
insserv: exiting now!
insserv: Service mountall has to be enabled to start service mountall-bootclean
insserv: exiting now!
insserv: Service checkfs has to be enabled to start service mountall
insserv: Service checkroot-bootclean has to be enabled to start service mountall
insserv: exiting now!
insserv: Service mountkernfs has to be enabled to start service mountdevsubfs
insserv: exiting now!
insserv: Service mountnfs has to be enabled to start service mountnfs-bootclean
insserv: exiting now!
insserv: Service urandom has to be enabled to start service networking
insserv: exiting now!
insserv: Service mountdevsubfs has to be enabled to start service nvidia-kernel
insserv: exiting now!
insserv: Service udev has to be enabled to start service plymouth
insserv: exiting now!
insserv: Service networking has to be enabled to start service tarent-server
insserv: Service ifupdown has to be enabled to start service tarent-server
insserv: exiting now!
retry (y/n)? y
insserv: Service mountdevsubfs has to be enabled to start service bootlogd
insserv: exiting now!
insserv: Service checkroot has to be enabled to start service checkfs
insserv: exiting now!
insserv: Service checkroot has to be enabled to start service
checkroot-bootclean
insserv: exiting now!
insserv: Service mountdevsubfs has to be enabled to start service checkroot
insserv: exiting now!
insserv: Service mountdevsubfs has to be enabled to start service hdparm
insserv: exiting now!
insserv: Service mountdevsubfs has to be enabled to start service hwclock
insserv: exiting now!
insserv: Service mountdevsubfs has to be enabled to start service lvm2
insserv: exiting now!
insserv: Service mdadm-raid has to be enabled to start service mdadm
insserv: exiting now!
insserv: Service mountall has to be enabled to start service mountall-bootclean
insserv: exiting now!
insserv: Service checkfs has to be enabled to start service mountall
insserv: Service checkroot-bootclean has to be enabled to start service mountall
insserv: exiting now!
retry (y/n)? y
insserv: Service checkroot has to be enabled to start service checkfs
insserv: exiting now!
insserv: Service checkroot has to be enabled to start service
checkroot-bootclean
insserv: exiting now!
insserv: Service mountall has to be enabled to start service mountall-bootclean
insserv: exiting now!
insserv: Service checkfs has to be enabled to start service mountall
insserv: Service checkroot-bootclean has to be enabled to start service mountall
insserv: exiting now!
retry (y/n)? y
insserv: Service mountall has to be enabled to start service mountall-bootclean
insserv: exiting now!
retry (y/n)? y
retry (y/n)? n
root@tglase:/etc # cat reinit
#!/bin/mksh
cd /etc
rm rc?.d/{S,K}*
typeset -l l=
while [[ $l != n ]]; do
for x in init.d/*; do
[[ -s $x ]] || continue
x=${x##*/}
[[ $x = *@(.dpkg|README|skeleton)* ]] && continue
[[ $x = rc?(S) ]] && continue
insserv -d "$x"
done
l=
while [[ $l != @(y|n) ]]; do
print -n "retry (y/n)? "
read l
done
done
Eventually, I got a bootable system back. Thank you!
Re: Delegation for the Release Team
Lucas Nussbaum writes ("Re: Delegation for the Release Team"):
> On 06/01/14 at 11:56 +, Neil McGovern wrote:
> > Explicitly again: Please see the last 7 years worth of bits mails, where
> > the release team have lowered this without advance notice, for BSPs etc.
...
> First, I do not think that we have a NMU *policy*. What we have is a set
> of (non-binding) recommended procedures, including recommended delays,
I think regarding our NMU policy as non-binding is a very bad idea.
NMUs are an important area of interaction between maintainers and
other contributors. Given the social contest, I think it is very
important that we have a clear understanding of what kind of NMU is
permissible when. Anything else is a recipe for people with different
understandings of the rules to end up arguing.
Can you imagine the reaction of a maintainer team if an NMUer
justified a breach of the policy on the grounds that it's not binding
but only "guidelines" ? I think the reaction here on -devel would be
unfavourable too.
> I think that this part of developers-reference, like any part of
> dev-ref, can be changed by any DD, following a process similar to the
> one the release team used in 2011:
> > - the release team announced its intention to change the policy in
> > https://lists.debian.org/debian-devel-announce/2011/03/msg00016.html
> > - #625449 was filed against developers-reference
> > - there was some discussion
> > - the proposed change made it into developers-reference
This is obviously impractical, for, for example, a BSP.
> That is, propose a change and seek consensus.
Given Lucas's attitude, I would like to suggest to the release team
that they file a bug against the the Developers' Reference, containing
a proposed change explicitly authorising the release team to vary the
NMU rules. That ought to satisfy Lucas's idea of the proper process
and put us back to the status quo ante.
Ian.
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/21194.43171.375610.596...@chiark.greenend.org.uk
Bug#734369: ITP: plasmate -- tool specifically tailored to creating Plasma Workspace add-ons
Package: wnpp Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org Package name: plasmate Version: 1.0 Upstream Author: Plasma Workspaces team URL: http://projects.kde.org/plasmate License: GPL2 Description: small IDE taylored for development of Plasma components, such as Widgets, Runners, Dataengines. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1503934.jqFpMxkhyB@sephirot
Re: 'tty' output on kFreeBSD, etc. within sbuild
On 06/01/2014 12:39, Ian Jackson wrote:
> Alastair McKinstry writes ("'tty' output on kFreeBSD, etc. within sbuild"):
>> Can anyone answer the following question which is puzzling me;
>> I have a piece of csh code which gets called during the build of a package
>> i'm maintaining. it does the following:
>>
>> echo "useful information" > /dev/tty
>>
>> within the script. (stdout, stderr being redirected, I think).
> Others have explained why you shouldn't do this.
>
> If you want to bypass some redirection in the rest of your package's
> build system, you could stash a copy of stderr in fd 3 or 5 or
> something (eg, in the rules file, with 3>&2), and then write to fd 5.
>
> But perhaps more information would enable us to give better advice.
>
> Thanks,
> Ian.
>
>
Thanks, I've been able to adapt the build scripts so it is not necessary;
they just output to stdout.
Regards
Alastair
--
Alastair McKinstry , ,
http://blog.sceal.ie
Anyone who believes exponential growth can go on forever in a finite world
is either a madman or an economist - Kenneth Boulter, Economist.
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/52cab929.9050...@sceal.ie
Bug#734374: ITP: kde-connect -- tool to integrate the KDE desktop with your mobile devices
Package: wnpp Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org Package name: kde-connect Version: 1.0 Upstream Author: Albert Vaca Cintora URL: http://albertvaka.wordpress.com/ License: GPL Description: set of plugins and services for kde to integrate mobile devices with KDE. At the moment it only supports Android ones. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1731023.Tv9pofjEas@sephirot
Re: Delegation for the Release Team
On 06/01/14 at 12:59 +, Ian Jackson wrote:
> Lucas Nussbaum writes ("Re: Delegation for the Release Team"):
> > On 06/01/14 at 11:56 +, Neil McGovern wrote:
> > > Explicitly again: Please see the last 7 years worth of bits mails, where
> > > the release team have lowered this without advance notice, for BSPs etc.
> ...
> > First, I do not think that we have a NMU *policy*. What we have is a set
> > of (non-binding) recommended procedures, including recommended delays,
>
> I think regarding our NMU policy as non-binding is a very bad idea.
> NMUs are an important area of interaction between maintainers and
> other contributors. Given the social contest, I think it is very
> important that we have a clear understanding of what kind of NMU is
> permissible when. Anything else is a recipe for people with different
> understandings of the rules to end up arguing.
>
> Can you imagine the reaction of a maintainer team if an NMUer
> justified a breach of the policy on the grounds that it's not binding
> but only "guidelines" ? I think the reaction here on -devel would be
> unfavourable too.
I agree with you that the NMU recommended practices must be clear, and
leave little place for interpretation. I think that [1] is reasonably
clear in terms of what's generally considered acceptable or not, even
though there's always place for improvement.
[1] http://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#nmu
I disagree that we should have *rules* because, given the social
context, I find it important to leave space to adapt to each case.
For example, if I had a fix for #713183 (RC bug against pyg, opened
on 2013-06-22, no action since then, no co-maintainer, maintainer
looks inactive, popcon=3), I wouldn't have a problem uploading with
a 0-day delay.
If I thought I had a fix for #727786 (RC bug against eglibc, opened
on 2013-10-26, last action on 2013-11-12, maintained by an active
team, popcon=158880), I don't think that uploading with a 0-day delay
would be a very good idea.
Problem is, there are many cases between those extremes. If you turn the
NMU recommended practices into rules, you could create or reinforce the
feeling that 0-day NMUs are a perfectly valid option in both cases
described above.
> > I think that this part of developers-reference, like any part of
> > dev-ref, can be changed by any DD, following a process similar to the
> > one the release team used in 2011:
> > > - the release team announced its intention to change the policy in
> > > https://lists.debian.org/debian-devel-announce/2011/03/msg00016.html
> > > - #625449 was filed against developers-reference
> > > - there was some discussion
> > > - the proposed change made it into developers-reference
>
> This is obviously impractical, for, for example, a BSP.
>
> > That is, propose a change and seek consensus.
>
> Given Lucas's attitude, I would like to suggest to the release team
> that they file a bug against the the Developers' Reference, containing
> a proposed change explicitly authorising the release team to vary the
> NMU rules. That ought to satisfy Lucas's idea of the proper process
> and put us back to the status quo ante.
Do you see a problem with the current NMU recommended practices, that
you would like to fix? I'm asking because the current ones have been
defined 2.5 years ago, and I don't remember much discussion about them
since then. Maybe we could save everybody's time, and have that
discussion about who is allowed to change them when there's a change
that someone wants to do.
Also, I'm surprised that you didn't comment on the last part of my mail.
Lucas
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20140106142054.ga21...@xanadu.blop.info
Re: GPLv2-only considered harmful [was Re: GnuTLS in Debian]
On Sat, Jan 04, 2014 at 03:13:01AM +, Clint Adams wrote: > On Wed, Jan 01, 2014 at 10:58:32AM +0100, David Weinehall wrote: > > That's also why I *don't* use BSD-style licenses for software that > > I write, but rather GPLv2 or LGPLv2.1. > > So if someone takes your LGPLv2.1-only software and adds GPLv2-only > code to it, do you feel similarly betrayed because you can't take > that code back? Yes; that ruins the whole purpose of choosing of the LGPL -- not only does the GPL not allow proprietary software to link against it (which is, for me, the whole point of licensing a library under the LGPL), but a change from LGPL to GPL is also oneway. The only situation I find such a license transformation morally ok is when taking parts of the code to incorporate in a project (let's say that a library contains a neat utility function that might be useful in another project. Linking against a library just for the sake of a single utility function is pretty over the top, but borrowing that code (properly credited, of course) feels perfectly fine. Regards: David -- /) David Weinehall /) Rime on my window (\ // ~ // Diamond-white roses of fire // \) http://www.acc.umu.se/~tao/(/ Beautiful hoar-frost (/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140106150732.gd25...@hirohito.acc.umu.se
Re: 'tty' output on kFreeBSD, etc. within sbuild
Alastair McKinstry writes ("Re: 'tty' output on kFreeBSD, etc. within sbuild"):
> On 06/01/2014 12:39, Ian Jackson wrote:
> > But perhaps more information would enable us to give better advice.
>
> Thanks, I've been able to adapt the build scripts so it is not necessary;
> they just output to stdout.
Great, thanks.
Ian.
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/21194.51175.579425.166...@chiark.greenend.org.uk
Re: GPLv2-only considered harmful [was Re: GnuTLS in Debian]
On 6 January 2014 15:07, David Weinehall wrote: > > On Sat, Jan 04, 2014 at 03:13:01AM +, Clint Adams wrote: > > On Wed, Jan 01, 2014 at 10:58:32AM +0100, David Weinehall wrote: > > > That's also why I *don't* use BSD-style licenses for software that > > > I write, but rather GPLv2 or LGPLv2.1. > > > > So if someone takes your LGPLv2.1-only software and adds GPLv2-only > > code to it, do you feel similarly betrayed because you can't take > > that code back? > > Yes; that ruins the whole purpose of choosing of the LGPL -- > not only does the GPL not allow proprietary software to link > against it (which is, for me, the whole point of licensing a library > under the LGPL), but a change from LGPL to GPL is also oneway. > > The only situation I find such a license transformation morally ok is > when taking parts of the code to incorporate in a project (let's say > that a library contains a neat utility function that might be useful in > another project. Linking against a library just for the sake of a > single utility function is pretty over the top, but borrowing that code > (properly credited, of course) feels perfectly fine. > Well, instead of using "or later" clause, one can dual/tripple/multiple license code under licenses one is ok with. E.g. GPLv2 | GPLv3 and _without and later_ But GPL text does confuse me as a whole, no modifications nor derivate works of the GPL license text are allowed, and the original text has "and later" clause - is licensing without "and later" constitues modification of the GPL license text, which is prohibited and thus all GPL licensed software is, in-fact, with "and later" clause? I guess it's a more of debian-legal@ question rather than debian-devel@. -- Regards, Dimitri. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/canbhlugfjpoabivfds7n1q6gfnxbt_f3stapn6cfppwpbvj...@mail.gmail.com
Re: Delegation for the Release Team
Lucas Nussbaum writes ("Re: Delegation for the Release Team"):
> On 06/01/14 at 12:59 +, Ian Jackson wrote:
> > Given Lucas's attitude, I would like to suggest to the release team
> > that they file a bug against the the Developers' Reference, containing
> > a proposed change explicitly authorising the release team to vary the
> > NMU rules. That ought to satisfy Lucas's idea of the proper process
> > and put us back to the status quo ante.
>
> Do you see a problem with the current NMU recommended practices, that
> you would like to fix? [...]
Well, Neil raised the question of bug squashing parties. They aren't
mentioned in the dev ref.
Also, the release team have historically occasionally put out
announcements that NMU rules would be relaxed for other reasons, such
as for release goals.
So I think the current dev ref text doesn't reflect our recent
practice.
> I'm asking because the current ones have been
> defined 2.5 years ago, and I don't remember much discussion about them
> since then. Maybe we could save everybody's time, and have that
> discussion about who is allowed to change them when there's a change
> that someone wants to do.
Perhaps it's just that everyone had thought that the release team's
announcements are sufficient to make exceptions to the rules in the
dev ref. It may be that that was the wrong process, and that power
wasn't really in the hands of the release team.
But AFAIAA pretty much everyone has gone along with it all this time
and deferred to release team decisions without questioning the basis
of their authority (that question having only arisen as a side-effect
of the team's DPL delegation). That suggests that the release team
have done well at making these decisions and should continue to do so.
In which case the right fix is to regularise the basis for their
decisionmaking.
> Also, I'm surprised that you didn't comment on the last part of my mail.
(Regarding the TC.) Well, of course I'm on the TC and the TC has the
power to rule on disputes about the dev ref. But right now I don't
see such a dispute.
I'm hoping that if Neil files a bug along the lines I suggested, the
dev ref maintainers would make the change as requested. That would
solve the problem completely and everyone would be happy, right ?
Perhaps there are people who don't want decisions on BSPs, release
goal NMU criteria, etc., to be made by the release team. But I think
anyone with that opinion should say who should make those decisions
instead.
Ian.
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/21194.51896.171660.908...@chiark.greenend.org.uk
Re: Delegation for the Release Team
On 06/01/14 at 15:24 +, Ian Jackson wrote:
> Lucas Nussbaum writes ("Re: Delegation for the Release Team"):
> > Also, I'm surprised that you didn't comment on the last part of my mail.
>
> (Regarding the TC.) Well, of course I'm on the TC and the TC has the
> power to rule on disputes about the dev ref. But right now I don't
> see such a dispute.
No, I was talking about the fact that the DPL can't delegate the power
to change an NMU policy, because that's a power that the DPL doesn't
have. (6.1.1)
> I'm hoping that if Neil files a bug along the lines I suggested, the
> dev ref maintainers would make the change as requested. That would
> solve the problem completely and everyone would be happy, right ?
Even if Neil was a member of the release team not so long ago, I think
that it would make more sense if a current member of the release team
filed that bug on behalf of the release team.
Lucas
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20140106154746.ga27...@xanadu.blop.info
Re: Delegation for the Release Team
On Mon, Jan 6, 2014 at 7:59 AM, Ian Jackson wrote:
> Lucas Nussbaum writes ("Re: Delegation for the Release Team"):
>> On 06/01/14 at 11:56 +, Neil McGovern wrote:
>> > Explicitly again: Please see the last 7 years worth of bits mails, where
>> > the release team have lowered this without advance notice, for BSPs etc.
> ...
>> First, I do not think that we have a NMU *policy*. What we have is a set
>> of (non-binding) recommended procedures, including recommended delays,
>
> I think regarding our NMU policy as non-binding is a very bad idea.
> NMUs are an important area of interaction between maintainers and
> other contributors. Given the social contest, I think it is very
> important that we have a clear understanding of what kind of NMU is
> permissible when. Anything else is a recipe for people with different
> understandings of the rules to end up arguing.
Additional layers of bureaucracy and inflexibility are the opposite
direction that the project should be going in.
> Can you imagine the reaction of a maintainer team if an NMUer
> justified a breach of the policy on the grounds that it's not binding
> but only "guidelines" ? I think the reaction here on -devel would be
> unfavourable too.
That is already effectively "enforced" by public shaming (mostly by
the release team). It would be nice if those engaged in that
enforcement were more kind. A simple tip to devref would be most of
the time effective.
Best wishes,
Mike
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/CANTw=MOggZiAS9vpUC9K+TMcpc622uaibp4sPgU=odwnjg3...@mail.gmail.com
Re: Delegation for the Release Team
On Mon, 06 Jan 2014 15:24:40 +, Ian Jackson wrote: FWIW, I have no strong opinion if something about NMU rules should be in the RT delegation; just adding some experiences / data points: > > Do you see a problem with the current NMU recommended practices, that > > you would like to fix? [...] > Well, Neil raised the question of bug squashing parties. They aren't > mentioned in the dev ref. From my experience, I never had the need for different NMU practices/rules during BSPs. NMUs are NMUs, no matter if I'm sitting at home fixing RC bugs or around a table with other Debian guys. Looking into the d-d-a archives, I find something about NMUs during BSPs in May 2007 (<20070513172244.ga14...@solar.ftbfs.de>) for the last time, and then (and since then, e.g. <47ccf6ce.7050...@debian.org> in March 2008) the "everlasting BSP" announcement in September 2007 (<20070901130447.gh27...@zomers.be>). AFAICS this made its way into DevRef via #625449 in March 2011. In <20110329095102.gx37...@feta.halon.org.uk> (which leads to this bug / DevRef change), the RT mentions that the "perpetual 0-day NMU policy ... has worked well for the past five years, and so will be submitting a bug against dev-ref to make this official." > Also, the release team have historically occasionally put out > announcements that NMU rules would be relaxed for other reasons, such > as for release goals. The last occurrence I found in a quick look in the d-d-a archives was from March 2009. (<20090302105458.GA3762@rivendell>) > So I think the current dev ref text doesn't reflect our recent > practice. My impression is different: I think recent (as in: quite a few years already) practice is exactly as it's written down in DevRef. > > I'm asking because the current ones have been > > defined 2.5 years ago, and I don't remember much discussion about them > > since then. Maybe we could save everybody's time, and have that > > discussion about who is allowed to change them when there's a change > > that someone wants to do. > Perhaps it's just that everyone had thought that the release team's > announcements are sufficient to make exceptions to the rules in the > dev ref. Maybe, except that there haven't been any I'm aware of since the last DevRef change :) > But AFAIAA pretty much everyone has gone along with it all this time > and deferred to release team decisions without questioning the basis > of their authority (that question having only arisen as a side-effect > of the team's DPL delegation). That suggests that the release team > have done well at making these decisions and should continue to do so. > In which case the right fix is to regularise the basis for their > decisionmaking. Again, no objection from me against writing down somewhere that the RT has a privileged role in adapting NMU rules, in case this will be considered necessary at some point in the future. Cheers, gregor -- .''`. Homepage: http://info.comodo.priv.at/ - OpenPGP key 0xBB3A68018649AA06 : :' : Debian GNU/Linux user, admin, and developer - http://www.debian.org/ `. `' Member of VIBE!AT & SPI, fellow of the Free Software Foundation Europe `- NP: Davy Graham: Pretty Polly signature.asc Description: Digital signature
Re: Delegation for the Release Team
On Mon, 6 Jan 2014 12:26:14 -0500
Michael Gilbert wrote:
> On Mon, Jan 6, 2014 at 7:59 AM, Ian Jackson wrote:
> > Lucas Nussbaum writes ("Re: Delegation for the Release Team"):
> >> On 06/01/14 at 11:56 +, Neil McGovern wrote:
> >> > Explicitly again: Please see the last 7 years worth of bits
> >> > mails, where the release team have lowered this without advance
> >> > notice, for BSPs etc.
> > ...
> >> First, I do not think that we have a NMU *policy*. What we have is
> >> a set of (non-binding) recommended procedures, including
> >> recommended delays,
> >
> > I think regarding our NMU policy as non-binding is a very bad idea.
+1
> > NMUs are an important area of interaction between maintainers and
> > other contributors. Given the social contest, I think it is very
> > important that we have a clear understanding of what kind of NMU is
> > permissible when. Anything else is a recipe for people with
> > different understandings of the rules to end up arguing.
>
> Additional layers of bureaucracy and inflexibility are the opposite
> direction that the project should be going in.
The project needs to respect the work of hard pressed teams and *help*
those teams by having strict and clear rules. Wasting time arguing
about requirements which are too vague or flexible is the wrong
direction if you actually want teams to get anything done other than
answering questions on mailing lists and IRC.
Little makes teams less popular than saying "no" continuously, so make
the rules clear and let the team manage the rules themselves.
The main changes made to the NMU policy by the release team have been
to *reduce* the timeframes but that doesn't mean that the policy itself
should be non-binding.
> > Can you imagine the reaction of a maintainer team if an NMUer
> > justified a breach of the policy on the grounds that it's not
> > binding but only "guidelines" ? I think the reaction here on
> > -devel would be unfavourable too.
>
> That is already effectively "enforced" by public shaming (mostly by
> the release team).
Such enforcement is clearly insufficient.
I'm in favour of an NMU policy which pushes non-compliant NMUs to the
appropriate delayed queues automatically. Policy details to be specified
by the release team alone, managed automatically and without room for
"negotiation" (hassle) in order to free the team to actually get the
release into a good state.
NMU Policy must respond to the needs of the project through the whole
release cycle. That means letting the release team reduce the delays
needed before an NMU during a release freeze.
> It would be nice if those engaged in that
> enforcement were more kind. A simple tip to devref would be most of
> the time effective.
Try working with a team who spend most of their time telling people not
to do things. Too many people think being "kind" is equivalent to
"giving way" and take that as a hint to pester continuously "because
the initial response didn't actually say no categorically".
Developers shouldn't *need* to be pointed at the developer reference or
release team announcement emails.
--
Neil Williams
=
http://www.linux.codehelp.co.uk/
signature.asc
Description: PGP signature
Bug#734394: ITP: pyhusl -- conversions for HUSL (human-friendly HSL) color space
Package: wnpp Severity: wishlist Owner: Yaroslav Halchenko * Package name: pyhusl Version : 2.1.0 Upstream Author : Alexei Boronine * URL : https://github.com/boronine/pyhusl * License : MIT Programming Lang: Python Description : conversions for HUSL (human-friendly HSL) color space HUSL is a modified version of the CIE LCh_uv color space with a new saturation component. . This package provides a Python port of HUSL defining conversions to and from CIE LChuv. See http://www.boronine.com/husl/ for more information about HUSL. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140106193738.28834.30086.report...@novo.onerussian.com
Re: Delegation for the Release Team
On Mon, Jan 06, 2014 at 06:46:02PM +0100, gregor herrmann wrote: > Looking into the d-d-a archives, I find something about NMUs during > BSPs in May 2007 (<20070513172244.ga14...@solar.ftbfs.de>) for the > last time, and then (and since then, e.g. > <47ccf6ce.7050...@debian.org> in March 2008) the "everlasting BSP" > announcement in September 2007 (<20070901130447.gh27...@zomers.be>). > AFAICS this made its way into DevRef via #625449 in March 2011. > In <20110329095102.gx37...@feta.halon.org.uk> (which leads to this > bug / DevRef change), the RT mentions that the "perpetual 0-day NMU > policy ... has worked well for the past five years, and so will be > submitting a bug against dev-ref to make this official." For the record, I don't think the wording in the devref matches the NMU policy that the release team was encouraging prior to that. In particular, the devref says that a 0-day NMU should be done only if: [...] fixing only release-critical bugs older than 7 days, with no maintainer activity on the bug for 7 days and no indication that a fix is in progress This is definitely more conservative than what I recommended while RM. As far as I'm concerned, any time there is an RC bugfix included in the upload, unless there are other changes included that you have reason to believe the maintainer will disapprove of, it should automatically be a 0-day NMU. Otherwise, the effect is that we're telling NMUers they should choose between doing a thorough job of fixing the package while NMUing, and providing timely help to the release. Likewise, I think that an RC bug being old or new, touched by the maintainer or not, factors into the decision about whether to spend the effort on preparing an NMU; but once the NMU has been prepared, I don't think it usually makes much sense to upload with a delay... it may have been duplicated effort, but it doesn't benefit anyone to delay the upload once it's been done. So I think the current language in the devref is a conservative compromise based on the discussions at the time. I would not like to see it enshrined as a hard rule that NMUers are going to get yelled at if they violate. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: GPLv2-only considered harmful [was Re: GnuTLS in Debian]
Hi Dimitri, On Mon, 6 Jan 2014 15:22:09 +, Dimitri John Ledkov wrote: > But GPL text does confuse me as a whole, no modifications nor derivate > works of the GPL license text are allowed, and the original text has > "and later" clause - is licensing without "and later" constitues > modification of the GPL license text, which is prohibited and thus all > GPL licensed software is, in-fact, with "and later" clause? The GPL itself discusses this, in section 9 in GPL v2 and in section 14 in GPL v3. The notice that mentions the version you apply to your code comes after the "END OF TERMS AND CONDITIONS" line, so it's not actually part of the license (although it is part of the license document, which is what the "verbatim" clause applies to, in its entirety). When you apply the terms to your code, as I understand it, you're allowed to choose whichever version of the license you prefer, with or without the "or later" clause; you're not modifying the license document itself so that's OK. Regards, Stephen (IANAL and all that) signature.asc Description: PGP signature
Re: GPLv2-only considered harmful [was Re: GnuTLS in Debian]
Op 05-01-14 15:57, Clint Adams schreef: > On Sat, Jan 04, 2014 at 05:07:29PM +0100, Wouter Verhelst wrote: >> This goes for GPLvX "or later", but also for other "or later" licenses, >> where they exist. >> >> I'm convinced that the GPLv2 is a free license, but I'm so far undecided >> on the GPLv3 (mainly because I've not read the license text in much >> detail myself yet since it's far too long and I just never had the time). >> >> How is that in any way antisocial? > > Because licensing is a social activity and you're making it all about you. I guess that's something we heavily disagree about, then. Licensing is not a social activity, to me. Writing free software is social, sure, and so I do want to share my code with whomever *I* think deserves it. To do that, it is necessary to choose a license which allows people to use (and modify!) my code in ways that I think is reasonable. Since "reasonable" also includes "making sure that it can be mingled with other code," I have no good reason to choose a GPLvX-incompatible license, and I will go to great lengths to avoid that, if I can. However, having said that, the FSF has a history of making statements that I disagree with about what is "ethical" behaviour as a developer, and thus I cannot in good conscience trust them to come up with a license that will not disenfranchise people whom I think do not deserve to be disenfranchised. In that light, it would be wrong to allow the FSF to dictate what people can (or cannot) be allowed to do with my code. > I could go waste my time making up a license that addresses only the > things I care about. It wouldn't have an attribution requirement. > It would terminate on trademark-related legal action. It would thus > be incompatible with every other copyleft license out there. And that would be very silly. But then, I'm not suggesting that. [...] > I once licensed something under GPLv2-only because I was afraid of > what v3 might bring, but that turned out to be stupid and I'm glad > someone yelled at me to fix it early on, because it was incompatible > with v3+ FOR NO GOOD REASON. I concur that if you fully agree with the FSF's position, there is no good reason to license something v2-only. Understand that not everyone feels that way. -- This end should point toward the ground if you want to go to space. If it starts pointing toward space you are having a bad problem and you will not go to space today. -- http://xkcd.com/1133/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/52cb35e6.4050...@debian.org
Re: Delegation for the Release Team
Le Mon, Jan 06, 2014 at 04:47:46PM +0100, Lucas Nussbaum a écrit : > > I think that it would make more sense if a current member of the release team > filed that bug on behalf of the release team. I agree and need to say that I am surprised to read so many emails complaining for the release team, writtend by developers who are not in the release team. I think that the discussions on this list would go better if everybody gave more time to the main parties to react first. If it is about security, release, system administration, python, init systems, etc, why not waiting at least a few hours to see if members of the relevant team have something original to say ? Have a nice day, -- 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: http://lists.debian.org/20140106231446.gr22...@falafel.plessy.net
Bug#734418: ITP: gap-io -- low level C library IO bindings for GAP
Package: wnpp Severity: wishlist Owner: Jerome Benoit * Package name: gap-io Version : 4.2 Upstream Author : Max Neunhoeffer * URL : http://www-circa.mcs.st-and.ac.uk/~neunhoef/Computer/Software/Gap/io.html * License : GPL Programming Lang: C, GAP Description : low level C library IO bindings for GAP This GAP package brings to GAP a link to the standard UNIX I/O functionalities available through the C-library. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140107015510.16235.7839.report...@nen.dnsalias.org
