Re: Bug#597571: nodejs: non common executable name
On 21/09/2010 02:00, Carl Fürstenberg wrote: > 2010/9/21 Jérémy Lal : I also contacted debian-hams to see if they'd mind changing this binary name, and the answer is clearly no [1]. [1] http://lists.debian.org/debian-hams/2010/08/msg00031.html i posted a reply yesterday to that thread : http://lists.debian.org/debian-hams/2010/09/msg00015.html Jérémy. -- 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/4c985cc0.1080...@edagames.com
Bug#597613: ITP: libdist-zilla-plugins-cjm-perl -- CJM's plugins for Dist::Zilla
Package: wnpp Owner: Dominique Dumont Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org,debian-p...@lists.debian.org * Package name: libdist-zilla-plugins-cjm-perl Version : 3.01 Upstream Author : Christopher J. Madsen * URL : http://search.cpan.org/dist/Dist-Zilla-Plugins-CJM/ * License : Artistic or GPL-1+ Programming Lang: Perl Description : CJM's plugins for Dist::Zilla Collection of Dist::Zilla plugins. This package features the following Perl modules: * Dist::Zilla::Plugin::ArchiveRelease - Move the release tarball to an archive directory * Dist::Zilla::Plugin::GitVersionCheckCJM - Ensure version numbers are up-to- date * Dist::Zilla::Plugin::ModuleBuild::Custom - Allow a dist to have a custom Build.PL * Dist::Zilla::Plugin::TemplateCJM - Process templates, including version numbers & changes * Dist::Zilla::Plugin::VersionFromModule - Get distribution version from its main_module * Dist::Zilla::Role::ModuleInfo - Create Module::Build::ModuleInfo object from Dist::Zilla::File Dominique -- http://config-model.wiki.sourceforge.net/ -o- http://search.cpan.org/~ddumont/ http://www.ohloh.net/accounts/ddumont -o- http://ddumont.wordpress.com/ -- 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/201009211256.17548.dominique.dum...@hp.com
Bug#597618: ITP: libdist-zilla-plugin-prepender-perl -- prepend lines at the top of your perl files
Package: wnpp Owner: Dominique Dumont Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org,debian-p...@lists.debian.org * Package name: libdist-zilla-plugin-prepender-perl Version : 1.101590 Upstream Author : Jerome Quelin * URL : http://search.cpan.org/dist/Dist-Zilla-Plugin-Prepender/ * License : Artistic or GPL-1+ Programming Lang: Perl Description : prepend lines at the top of your perl files This Dist::Zilla plugin will prepend the specified lines in each Perl module or program within the distribution. For scripts having a shebang line, lines will be inserted just after it. This is useful to enforce a set of pragmas to your files (since pragmas are lexical, they will be active for the whole file), or to add some copyright comments, as the fsf recommends. Dominique -- http://config-model.wiki.sourceforge.net/ -o- http://search.cpan.org/~ddumont/ http://www.ohloh.net/accounts/ddumont -o- http://ddumont.wordpress.com/ -- 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/201009211406.24151.dominique.dum...@hp.com
Re: Bug#597571: nodejs: non common executable name
Carl Fürstenberg writes ("Re: Bug#597571: nodejs: non common executable name"):
> Policy only states "The maintainers should report this to the
> debian-devel mailing list and try to find a consensus about which
> program will have to be renamed. If a consensus cannot be reached,
> both programs must be renamed."; I don't see any consensus in the
> thread you linked to, so technically both must change at the moment :)
I wrote that bit of the policy and my intent was to try to punish
people for picking stupid names.
Yes, both binaries should be renamed. "node" is a ridiculous name for
a specific-purpose executable.
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/19608.43395.371240.670...@chiark.greenend.org.uk
Re: Bug#597571: nodejs: non common executable name
On Tue, Sep 21, 2010 at 01:48:03PM +0100, Ian Jackson wrote:
>
> Carl Fürstenberg writes ("Re: Bug#597571: nodejs: non common executable
> name"):
> > Policy only states "The maintainers should report this to the
> > debian-devel mailing list and try to find a consensus about which
> > program will have to be renamed. If a consensus cannot be reached,
> > both programs must be renamed."; I don't see any consensus in the
> > thread you linked to, so technically both must change at the moment :)
>
> I wrote that bit of the policy and my intent was to try to punish
> people for picking stupid names.
>
In this case, and many others, the only "people" punished are the
Debian packagers and users. The packagers because they have to create
patches to rename the binaries, and the users because the name is not
the same for either package in Debian as it is on other distros.
> Yes, both binaries should be renamed. "node" is a ridiculous name for
> a specific-purpose executable.
At this point in time I would agree. Twenty or so years ago when the
ax25 software was first being developed, node adequately described the
binary's function and was not so common a term.
We had a similar issue not that long ago with the ax25 package "listen".
It had been in Debian for a long time and then someone wanted to upload
something new that was also named "listen". Initially the ax25 package
name was kept, but later it was changed to "axlisten" and the (created
much later) audio player was allowed to keep the name.
Pat
--
Patrick Ouellette p...@flying-gecko.net
ne4po (at) arrl (dot) net Amateur Radio: NE4PO
What kind of change have you been in the world today?
signature.asc
Description: Digital signature
Re: Bug#596511: ITP: simon -- Open source speech recognition
Peter Grasch writes: >> Peter, have you prepared a source *.deb yet? It would be interesting to >> look at the code to understand how critical the non-free component is. > Sure. There are complete packages in the Ubuntu ppa: > https://launchpad.net/~grasch-simon-listens/+archive/simon/ The copyright file says: This package consists of four differently licensed parts: * The documentation is under the GFDL (see below); * Julius (everything in the folder julius/) is coverd by the Julius license (see below) * CMake modules are licensed under the BSD license (see below) * Everything else is covered by the GPLv2 One conclusion from earlier discussions about the Julius license on debian-legal was that it was non-free: http://www.mail-archive.com/debian-le...@lists.debian.org/msg40898.html The thread isn't completely clear to me what the exact problem is though... Is Julius dynamically linked to Simon? I wonder whether GPLv2 is compatible with the Julius license. /Simon -- 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/87mxrbz11k@mocca.josefsson.org
Re: Bug#596511: ITP: simon -- Open source speech recognition
Hi! One conclusion from earlier discussions about the Julius license on debian-legal was that it was non-free: http://www.mail-archive.com/debian-le...@lists.debian.org/msg40898.html The thread isn't completely clear to me what the exact problem is though... As far as I can work out the ambiguous advertising clause is the problem (as well as possibly clause 5 but that seems to be open for discussion). I agree that this clause is quite badly worded and already asked about it in the Julius forums (I am "bedahr"): http://julius.sourceforge.jp/forum/viewtopic.php?f=6&t=644- But I never got a reply. Is Julius dynamically linked to Simon? I wonder whether GPLv2 is compatible with the Julius license. Yes it is. The simon license contains a special exception to allow this. This is also covered here: http://www.simon-listens.org/wiki/index.php/Licensing Regards, Peter -- 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/4c98b8b3.6080...@simon-listens.org
Re: Bug#597571: nodejs: non common executable name
On 21/09/2010 14:48, Ian Jackson wrote:
> Carl Fürstenberg writes ("Re: Bug#597571: nodejs: non common executable
> name"):
>> Policy only states "The maintainers should report this to the
>> debian-devel mailing list and try to find a consensus about which
>> program will have to be renamed. If a consensus cannot be reached,
>> both programs must be renamed."; I don't see any consensus in the
>> thread you linked to, so technically both must change at the moment
>> :)
>
> I wrote that bit of the policy and my intent was to try to punish
> people for picking stupid names.
>
> Yes, both binaries should be renamed. "node" is a ridiculous name for
> a specific-purpose executable.
>
Wrong. nodejs still provides the binary nodejs and not _node_. So, nodejs can
stay as is. The rename would be necessary if both packages provide the
same binary (same filename), which is not the case here.
Please read again the bit of the policy you wrote.
Regards,
--
Mehdi Dogguy مهدي الدڤي
http://dogguy.org/
--
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/4c98b921.1080...@dogguy.org
Bug#597624: ITP: liblist-utilsby-perl -- higher-order list utility functions
Package: wnpp Severity: wishlist Owner: Angel Abad * Package name: liblist-utilsby-perl Version : 0.06 Upstream Author : Paul Evans * URL : http://search.cpan.org/~pevans/List-UtilsBy-0.06/ * License : Artistic or GPL-1 Programming Lang: Perl Description : higher-order list utility functions List::UtilsBy provides a number of list utility functions, all of which take an initial code block to control their behaviour. They are variations on similar core perl or List::Util functions of similar names, but which use the block to control their behaviour. -- 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/20100921133817.21580.12697.report...@goa
Re: Bug#597571: nodejs: non common executable name
Mehdi Dogguy writes ("Re: Bug#597571: nodejs: non common executable name"):
> Wrong. nodejs still provides the binary nodejs and not _node_. So, nodejs can
> stay as is. The rename would be necessary if both packages provide the
> same binary (same filename), which is not the case here.
Sorry, when I wrote in my posting by "both binaries should be renamed"
I meant "neither binary should be called `node'".
> Please read again the bit of the policy you wrote.
I was trying (and failing, sorry) to explain the reasoning behind the
policy, rather than insisting on the strict letter of its
interpretation.
I don't think the fact that the nodejs maintainer already renamed
their binary right from the beginning excuses the behaviour of the
"node" maintainer. ("node" is a really bad package name, too.)
So /usr/sbin/node from the "node" package should be renamed IMO.
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/19608.48023.679605.322...@chiark.greenend.org.uk
Re: Bug#597571: nodejs: non common executable name
Note that i tried to warn upstream nodejs several months ago, but it was already too late, so i renamed it to comply. Please also note that nodejs runs (js) scripts, so the renaming means each nodejs module[0] that may be packaged in the future, and that provides executables, will need to be patched accordingly. User scripts are at stake, too, and users are probably going to manually link nodejs to node. Nowadays nodejs users are mostly downloading the package from some ubuntu's ppa, instead of the debian package, because of that renaming problem. Jérémy. [0] http://github.com/ry/node/wiki/modules -- 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/4c98bf99.9070...@edagames.com
Bug#597631: ITP: fusionforge-oslc-cm-server -- OSLC-CM compatible server module for fusionforge trackers
Package: wnpp Severity: wishlist Owner: Olivier Berger * Package name: fusionforge-oslc-cm-server Upstream Author : Olivier Berger et al. * URL : https://picoforge.int-evry.fr/cgi-bin/twiki/view/Oslc/Web/FusionForgeOslcServer * License : GPL Programming Lang: PHP Description : OSLC-CM compatible server module for fusionforge trackers OSLC-CM is a standard specification for APIs for Change Management applications. It is based on Web technologies such as REST, RDF, or AJAX. This package provides an OSLC-CM V2 compatible server module for the FusionForge trackers. Note that I am also one of the upstream authors. The package will depend on gforge-web-apache2 (or fusionforge-web-apache2 someday), and will work over zendframework. Best regards, -- 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/20100921144953.30588.88627.report...@inf-8657.int-evry.fr
Re: Bug#596511: ITP: simon -- Open source speech recognition
Peter Grasch writes: > Hi! > >> One conclusion from earlier discussions about the Julius license on >> debian-legal was that it was non-free: >> >> http://www.mail-archive.com/debian-le...@lists.debian.org/msg40898.html >> >> The thread isn't completely clear to me what the exact problem is >> though... > As far as I can work out the ambiguous advertising clause is the > problem (as well as possibly clause 5 but that seems to be open for > discussion). > > I agree that this clause is quite badly worded and already asked about > it in the Julius forums (I am "bedahr"): > http://julius.sourceforge.jp/forum/viewtopic.php?f=6&t=644- > > But I never got a reply. OK. >> Is Julius dynamically linked to Simon? I wonder whether GPLv2 is >> compatible with the Julius license. > Yes it is. The simon license contains a special exception to allow this. > This is also covered here: > http://www.simon-listens.org/wiki/index.php/Licensing It refers to 'under certain conditions as described in each individual source file' but I cannot find conditions described in any of a random sample I made of source code files in Simon? Can you point to one file that has the conditions? All source code files that are built into a package linked to Julius needs to have the exception, I believe, otherwise the file is under the GPLv2+ only without the exception. Also, any external GPL code that Simon links to needs to have the same exception. Is there any external GPL code? /Simon -- 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/87lj6vxisf@mocca.josefsson.org
Re: Bug#597571: nodejs: non common executable name
On 21/09/2010 16:02, Patrick Ouellette wrote: > On Tue, Sep 21, 2010 at 03:54:41PM +0200, Mehdi Dogguy wrote: >> >> Wrong. nodejs still provides the binary nodejs and not _node_. So, >> nodejs can stay as is. The rename would be necessary if both >> packages provide the same binary (same filename), which is not the >> case here. >> > > Actually, from the discussion in debian-hams, nodejs provides a binary > named "node" - otherwise we would not need to have the discussion at > all since there would be no conflict. > Wrong. nodejs's maintainer wants to rename "bin/nodejs" to "bin/node"… that's why there was the discussion on debian-hams. (But then, whether the rename is appropriate is another story… IMO, it's not appropriate because the name is too generic. And as Ian already pointed out, even "node" should be renamed). $ dpkg -L nodejs | grep bin/ /usr/bin/nodejs Regards, -- Mehdi Dogguy مهدي الدڤي http://dogguy.org/ -- 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/4c98ca3b.3000...@dogguy.org
Re: Bug#597571: nodejs: non common executable name
On Tue, Sep 21, 2010 at 03:54:41PM +0200, Mehdi Dogguy wrote: > > Wrong. nodejs still provides the binary nodejs and not _node_. So, nodejs can > stay as is. The rename would be necessary if both packages provide the > same binary (same filename), which is not the case here. > Actually, from the discussion in debian-hams, nodejs provides a binary named "node" - otherwise we would not need to have the discussion at all since there would be no conflict. -- Patrick Ouellette p...@flying-gecko.net ne4po (at) arrl (dot) net Amateur Radio: NE4PO What kind of change have you been in the world today? -- 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/20100921140225.gb26...@flying-gecko.net
Re: Bug#597571: nodejs: non common executable name
On 21/09/2010 17:22, Patrick Ouellette wrote: > > You are quick with the "wrong" button. It's my new toy :) > The UPSTREAM nodejs is /usr/bin/node. The Debian package renamed it to > nodejs. > Did you say that before? I don't think so. Personally, I care about the Debian package only because the original bugreport (from where this discussion started) was against the Debian package and for a Debian specificity, not about the genericity of the name used for the shipped binary. Regards, -- Mehdi Dogguy مهدي الدڤي http://dogguy.org/ -- 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/4c98cea6.8080...@dogguy.org
Re: Bug#597571: nodejs: non common executable name
On Tue, Sep 21, 2010 at 05:07:39PM +0200, Mehdi Dogguy wrote: > > On 21/09/2010 16:02, Patrick Ouellette wrote: > > On Tue, Sep 21, 2010 at 03:54:41PM +0200, Mehdi Dogguy wrote: > >> > >> Wrong. nodejs still provides the binary nodejs and not _node_. So, > >> nodejs can stay as is. The rename would be necessary if both > >> packages provide the same binary (same filename), which is not the > >> case here. > >> > > > > Actually, from the discussion in debian-hams, nodejs provides a binary > > named "node" - otherwise we would not need to have the discussion at > > all since there would be no conflict. > > > > Wrong. nodejs's maintainer wants to rename "bin/nodejs" to "bin/node"… > that's why there was the discussion on debian-hams. (But then, whether the > rename is appropriate is another story… IMO, it's not appropriate because > the name is too generic. And as Ian already pointed out, even "node" > should be renamed). > > $ dpkg -L nodejs | grep bin/ > /usr/bin/nodejs > You are quick with the "wrong" button. The UPSTREAM nodejs is /usr/bin/node. The Debian package renamed it to nodejs. -- Patrick Ouellette p...@flying-gecko.net ne4po (at) arrl (dot) net Amateur Radio: NE4PO What kind of change have you been in the world today? -- 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/20100921152247.ga14...@flying-gecko.net
Bug#597641: ITP: visolate -- tool for engraving PCBs using CNCs
Package: wnpp Severity: wishlist Owner: chrysn * Package name: visolate Version : 2.0.0 Upstream Author : Marsette A. Vona, III * URL : http://www.mit.edu/~vona/Visolate/ * License : GPL Programming Lang: Java Description : tool for engraving PCBs using CNCs Visolate reads the gerber files describing printed circuit boards and converts them into the g-code needed to engrave they layout into a board using a CNC machine. Precise renditions of the original layout can be created as well as voronoi fillings of the original layout, shortening the toolpath. there are some issues to be resolved with upstream concerning which version is the latest, but these can be expected to be resolved easily. as far as packaging itself is concerned, the current status relies on javahelper and hardly does anything but call javahelper and include a binary wrapper. for sake of completeness, i should mention that i have no experience in java programming at all -- for all but trivial fixes in the code, i will have to rely on upstream or others. that whole jar business seems to be handled by jh quite well, fortunately :-) -- To use raw power is to make yourself infinitely vulnerable to greater powers. -- Bene Gesserit axiom signature.asc Description: Digital signature
Re: Bug#597571: nodejs: non common executable name
On Tue, Sep 21, 2010 at 05:26:30PM +0200, Mehdi Dogguy wrote: > > Did you say that before? I don't think so. Personally, I care about the > Debian package only because the original bugreport (from where this > discussion started) was against the Debian package and for a Debian > specificity, not about the genericity of the name used for the shipped binary. Part of the historical discussion on debian-hams and Jéré mentioned it in this thread today. Pat -- Patrick Ouellette p...@flying-gecko.net ne4po (at) arrl (dot) net Amateur Radio: NE4PO What kind of change have you been in the world today? -- 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/20100921160102.gb14...@flying-gecko.net
Re: Bug#596511: ITP: simon -- Open source speech recognition
Hi! Am 2010-09-21 16:39, schrieb Simon Josefsson: Is Julius dynamically linked to Simon? I wonder whether GPLv2 is compatible with the Julius license. Yes it is. The simon license contains a special exception to allow this. This is also covered here: http://www.simon-listens.org/wiki/index.php/Licensing It refers to 'under certain conditions as described in each individual source file' but I cannot find conditions described in any of a random sample I made of source code files in Simon? Can you point to one file that has the conditions? All source code files that are built into a package linked to Julius needs to have the exception, I believe, otherwise the file is under the GPLv2+ only without the exception. You are right, I forgot that exception but added it to the two files of the one class coming in direct contact with Julius (it's used somewhere else too but there it just calls external programs). Also, any external GPL code that Simon links to needs to have the same exception. Is there any external GPL code? Well of course - KDE. This is getting ridiculously frustrating. It's not that I don't think it's an important issue but I guess if you'd gather all involved parties and ask them if the current setup would be ok I am pretty sure everyone would agree. Oh well I guess that just comes with the territory. I obviously can't hack this into simon 0.3.0 but for the next version, would it help if I split the Julius-interfacing part into a plugin that doesn't link to KDE? This would be the easiest option in my opinion but as I understand it it would mean to distribute the plugin seperately? If Julius is not "free" in Debian eyes this would mean that simon becomes pretty much useless to be honest. Regards, Peter -- 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/4c98f5b1.9030...@simon-listens.org
Some mails from Ubuntu bugs not forwarded to the PTS
Hi, If you use the derivatives-bugs[1] PTS keyword to receive bugmail from Ubuntu, it is possible that you did not receive some mails during the last few days. Due to the migration of qa.debian.org to another host, the script that receives emails from Launchpad and forwards them to the appropriate package on the PTS was temporarily broken by a different configuration of the local mail server. So, if you rely on this feature to be warned of new or modified Ubuntu bugs, it might be a good idea to check the Developer's Packages Overview, or the PTS web interface. [1] http://www.debian.org/doc/developers-reference/resources.html#pts-commands - 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/20100921205257.ga2...@xanadu.blop.info
Re: Bug#596511: ITP: simon -- Open source speech recognition
Peter Grasch writes: > Hi! > > Am 2010-09-21 16:39, schrieb Simon Josefsson: Is Julius dynamically linked to Simon? I wonder whether GPLv2 is compatible with the Julius license. >>> Yes it is. The simon license contains a special exception to allow this. >>> This is also covered here: >>> http://www.simon-listens.org/wiki/index.php/Licensing >> It refers to 'under certain conditions as described in each individual >> source file' but I cannot find conditions described in any of a random >> sample I made of source code files in Simon? Can you point to one file >> that has the conditions? All source code files that are built into a >> package linked to Julius needs to have the exception, I believe, >> otherwise the file is under the GPLv2+ only without the exception. > You are right, I forgot that exception but added it to the two files > of the one class coming in direct contact with Julius (it's used > somewhere else too but there it just calls external programs). > > >> Also, any external GPL code that Simon links to needs to have the same >> exception. Is there any external GPL code? > Well of course - KDE. I believe kdelibs is LGPL, so maybe you are OK. It depends on what parts of KDE is used. > This is getting ridiculously frustrating. It's not that I don't think > it's an important issue but I guess if you'd gather all involved > parties and ask them if the current setup would be ok I am pretty sure > everyone would agree. Oh well I guess that just comes with the > territory. I know the pain, I've ended up rewriting several projects because of license problems with earlier implementations. What I have learned is that you should react to license issues as soon as possible, or you'll end up investing a lot of work into something that needs to be redesigned. > I obviously can't hack this into simon 0.3.0 but for the next version, > would it help if I split the Julius-interfacing part into a plugin > that doesn't link to KDE? This would be the easiest option in my > opinion but as I understand it it would mean to distribute the plugin > seperately? > > If Julius is not "free" in Debian eyes this would mean that simon > becomes pretty much useless to be honest. I don't really have an opinion whether it is free or not yet, but it looks complicated. /Simon -- 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/87tylirfuc@mocca.josefsson.org
unstable/testing/[pending/frozen/]stable
Hi All, CUT discussions at debconf10 and recent news of the birth of Linux Mint Debian Edition (LMDE) [1] show how valuable and unique Debian's rolling distribution (testing) is. But every freeze in the preparation to upcoming stable release in effect, eliminates 'testing' (and actually unstable... since experimental is not a complete distribution and we can't force users to use something with that name ;) ) until new stable sees the world. I wondered, why don't we have [experimental/]unstable(sid)/testing(e.g squeeze)/stable *constantly* present and functioning all the time the same way. Then upon freeze we just copy the state of unstable -> pending testing(squeeze) -> frozen(squeeze, e.g together with a codename) and link new codename (e.g. wheezy) against testing. NB I am having some deja vu that 'frozen' used to be used explicitly in the archive... is that so? Then unstable/testing would roll further as usual, and pending->frozen according to the freeze schedule. This would enable CUTs, fulfill the ideas behind LMDE to have something rolling without hickups, and users of 'testing' (and unstable) would enjoy testing/unstable the way they usually do. I understand that it would require more work, but I think benefits would overweight the burden. But I cannot be first thinking about that, and I bet there were good reasons why such approach was not taken -- could anyone enlighten/point me to the shortcomings? [1] http://www.linuxmint.com/blog/?p=1527 -- .-. =-- /v\ = Keep in touch// \\ (yoh@|www.)onerussian.com Yaroslav Halchenko /( )\ ICQ#: 60653192 Linux User^^-^^[17] signature.asc Description: Digital signature
Re: unstable/testing/[pending/frozen/]stable
On Tue, 21 Sep 2010 20:52:09 -0400 Yaroslav Halchenko wrote: > Hi All, > > CUT discussions at debconf10 and recent news of the birth of Linux > Mint Debian Edition (LMDE) [1] show how valuable and unique Debian's > rolling distribution (testing) is. But every freeze in the > preparation to upcoming stable release in effect, eliminates > 'testing' (and actually unstable... I don't see what that is meant to mean. Testing and unstable are constantly present and functional during a freeze. What happens is that the pace of new (disruptive) uploads and migrations is manually limited. i.e. the stability and functionality of testing and unstable *rise* during a release freeze simply because new transitions are not started - in unstable or testing. Unstable needs to be managed during a freeze because it is the destination of uploads which fix RC bugs in testing. If there was a new migration/transition in unstable affecting this package, the new upload cannot migrate (and cannot fix the bug). Testing-proposed-updates isn't an excuse for making a mess of unstable during a freeze. > since experimental is not a > complete distribution and we can't force users to use something with > that name ;) ) until new stable sees the world. I wondered, why don't > we have > > [experimental/]unstable(sid)/testing(e.g squeeze)/stable > > *constantly* present and functioning all the time the same way. So when and where are library transitions meant to occur? Transitions are always disruptive, always cause some packages to be non-functional or non-installable. There has to be somewhere (unstable) where libfoo2 can be uploaded with libfoo2-dev so that all packages which depend on libfoo1 can start the migration to the new API. As the migration starts, there is a period (which in the case of GTK1->2 took several years) where many packages in unstable are uninstallable or FTBFS or just horribly buggy. > Then upon freeze we just copy the state of > unstable -> pending > testing(squeeze) -> frozen(squeeze, e.g together with a codename) > and link new codename (e.g. wheezy) against testing. unstable is not compatible with *-proposed-updates - nor is having *-proposed-updates an excuse for starting new transitions in unstable during a freeze. > Then unstable/testing would roll further as usual How does a major, disruptive, transition get done? >, and pending->frozen > according to the freeze schedule. This would enable CUTs, fulfill > the ideas behind LMDE to have something rolling without hickups, and > users of 'testing' (and unstable) would enjoy testing/unstable the way > they usually do. > > I understand that it would require more work, but I think benefits > would overweight the burden. > > But I cannot be first thinking about that, and I bet there were good > reasons why such approach was not taken -- could anyone > enlighten/point me to the shortcomings? In a word, transitions. -- Neil Williams = http://www.data-freedom.org/ http://www.linux.codehelp.co.uk/ http://e-mail.is-not-s.ms/ pgp2oooMpquY1.pgp Description: PGP signature
Re: unstable/testing/[pending/frozen/]stable
On Wed, Sep 22, 2010 at 07:31:45AM +0100, Neil Williams wrote: > > Then unstable/testing would roll further as usual > > How does a major, disruptive, transition get done? I think his proposal boils down to this: we *always* have unstable and testing to upload whatever we want and handle transitions when we like. Then, parallel to unstable/testing, there would be the pending/frozen suites to work on the release. Saying it a bit differently, we would *also* already be working on release+1 while release is being frozen. I kind of like the idea. To give an example with package names, I would already upload iceweasel 3.6 to unstable, thus breaking all xulrunner-dev reverse dependencies until they are fixed to use xulrunner 1.9.2, while keeping updates for iceweasel 3.5 in pending/frozen. It would also allow me to push iceweasel 4.0 betas to experimental, where they would be better suited than their current location, where they are not even built on non x86/x86-64. This could be more work, but I understand that for people who want to do it, the testing freeze time is frustrating. Mike PS: for my personal needs, some way to get random packages autobuilt would already be helpful (call that ppa if you want). -- 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/20100922064731.ga16...@glandium.org
Re: Google Summer of Code 2010 Debian Report
Le lundi 20 septembre 2010 à 12:47 +0200, Adrian von Bidder a écrit : > Hi Arthur, > > On Monday 20 September 2010 11.37:04 Obey Arthur Liu wrote: > [GSoC report] > > Hmm. It would have been nice to hear about what the students did and how > far they got in their GSoC projects instead of what they did at DC10. > +1 I'd have been pleased to get some update about "Debbugs Bug Reporting and Manipulation API" too... any pointer ? Thanks in advance. Best regards, -- Olivier BERGER http://www-public.it-sudparis.eu/~berger_o/ - OpenPGP-Id: 2048R/5819D7E8 Ingénieur Recherche - Dept INF Institut TELECOM, SudParis (http://www.it-sudparis.eu/), Evry (France) -- 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/1285138594.3410.2.ca...@inf-8657.int-evry.fr
