Re: Minified files and source code requirement

2011-10-27 Thread Raphael Hertzog 
On Thu, 27 Oct 2011, Paul Wise wrote:
> On Thu, Oct 27, 2011 at 1:08 AM, Raphael Hertzog wrote:
> > I don't agree that minified files are a violation of DFSG #2. If the
> > library is under the GPL then it would be a problem because it's not the
> > preferred form of modification.
> 
> I think this is exactly the same as xserver-xorg-video-nv, which
> contained obfuscated C code instead of the actual source code. I
> personally considered that a DFSG violation but I guess you would not?

I would consider it a DFSG violation. It's all a matter of intent.

Obfuscated != minified.

In one case we have unreadable C code where you don't have access to
the unobfuscated version and this was done on purpose by the upstream
authors to make it difficul to understand what the code does.

In the other case you have unreadable javascript code but you can easily
find the corresponding source code on numerous places (sometimes in the
corresponding Debian package, sometimes in an older version of it on
snapshot.debian.org and generally on its upstream website). The
minification was not even done by the upstream that uses that file but
by the original project who delivers both files. The minification is not
done to make it more difficult to understand the code or make changes, but
to save time when downloading the file.

Requiring the non-minified file to be provided in the same source package
is not a very productive use of our time. In particular if you don't go
to the step beyond which is to modify the upstream build process to
regenerate the minified file from the original one. Otherwise modifying
that file in the source and rebuilding it does not have the expected
result.

I think it's great to encourage this sane behaviour, but it's not a
bug that's worth a serious severity.

> What is the preferred form for modification for a work (aka source) is
> highly context-dependent.

I share entirely the opinion of Russ who replied to this specific point.

We should not mix the minimal requirements that we have and our own
personal ideals in terms of what's needed to modify in sane conditions the
stuff what we are releasing.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Pre-order a copy of the Debian Administrator's Handbook and help
liberate it: http://debian-handbook.info/go/ulule-rh/


-- 
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/20111027070837.gm...@rivendell.home.ouaza.com

Re: Minified files and source code requirement

2011-10-27 Thread Raphael Hertzog 
Hi,

On Wed, 26 Oct 2011, Adam D. Barratt wrote:
> http://ftp-master.debian.org/REJECT-FAQ.html

Hum, it looks like some ftpmaster added a new entry in the FAQ (since it's
dated October 2011). Probably Mike O'Connor since he replied to #646729
and re-raised its severity.

Mike, it would be still nice to have some official answer to
<20111027070837.gm...@rivendell.home.ouaza.com>. At least so that the
reasoning of the FTP masters is recorded for posterity.

I'm not going to argue further since it looks like the consensus seems to
be to enforce this requirement for this specific case.

It would still be nice if ftpmasters mailed debian-devel when they
extend their FAQ to rule on new kinds of issues.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Pre-order a copy of the Debian Administrator's Handbook and help
liberate it: http://debian-handbook.info/go/ulule-rh/


-- 
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/20111027073507.gn...@rivendell.home.ouaza.com

Re: Minified files and source code requirement

2011-10-27 Thread Roland Mas 
Raphael Hertzog, 2011-10-27 09:08:37 +0200 :

[...]

>> I think this is exactly the same as xserver-xorg-video-nv, which
>> contained obfuscated C code instead of the actual source code. I
>> personally considered that a DFSG violation but I guess you would not?
>
> I would consider it a DFSG violation. It's all a matter of intent.

  There's a saying about the road to hell.

> Obfuscated != minified.

  Intent is all very well, but if the effects of the operation make the
resulting "code" unusable, even for the best of reasons, then said code
can't be said to be the source.

> In one case we have unreadable C code where you don't have access to
> the unobfuscated version and this was done on purpose by the upstream
> authors to make it difficul to understand what the code does.
>
> In the other case you have unreadable javascript code but you can
> easily find the corresponding source code on numerous places
> (sometimes in the corresponding Debian package, sometimes in an older
> version of it on snapshot.debian.org and generally on its upstream
> website). The minification was not even done by the upstream that uses
> that file but by the original project who delivers both files. The
> minification is not done to make it more difficult to understand the
> code or make changes, but to save time when downloading the file.

  Convenience is good, but actually providing source is a requirement
for Debian.  Unusable source isn't enough.

> Requiring the non-minified file to be provided in the same source
> package is not a very productive use of our time. 

  Right.  In the same way that providing the source for our binaries
isn't very productive, I guess, because who's going to use it when they
have the pre-built binaries?  I know this is an exaggeration, but
there's no substantial difference between the two cases.

> In particular if you don't go to the step beyond which is to modify
> the upstream build process to regenerate the minified file from the
> original one. Otherwise modifying that file in the source and
> rebuilding it does not have the expected result.
>
> I think it's great to encourage this sane behaviour, but it's not a
> bug that's worth a serious severity.

  With no particular hat on (except the one of a maintainer of a webapp
that uses a few JS libraries), I respectfully disagree.

>> What is the preferred form for modification for a work (aka source)
>> is highly context-dependent.
>
> I share entirely the opinion of Russ who replied to this specific point.
>
> We should not mix the minimal requirements that we have and our own
> personal ideals in terms of what's needed to modify in sane conditions
> the stuff what we are releasing.

  I thought that the minimal requirements were precisely designed to
reflect what's needed to do modifications in a sane way, but maybe
that's just me.

Roland.
-- 
Roland Mas

The price of liberty is eternal housekeeping.
  -- in Odds and Gods (Tom Holt)


-- 
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/874nyu7rdd@mirexpress.internal.placard.fr.eu.org

Re: Minified files and source code requirement

2011-10-27 Thread Pau Garcia i Quiles 
On Thu, Oct 27, 2011 at 10:47 AM, Roland Mas  wrote:
>> Requiring the non-minified file to be provided in the same source
>> package is not a very productive use of our time.
>
>  Right.  In the same way that providing the source for our binaries
> isn't very productive, I guess, because who's going to use it when they
> have the pre-built binaries?  I know this is an exaggeration, but
> there's no substantial difference between the two cases.

But we provide *source packages*. We do not provide the source in the
*binary* package.

That's what Raphael is talking about: having the minified and the
original (non-minified) JavaScript in the *same* package (which would
be the binary package, and also the source package).

I said this in the original thread and I'll repeat it here: if we have
the non-minified JavaScript, then I see no problem in providing only
the minified version in the binary package.

To me, these are equivalents:

Minified Javascript == ELF binaries

Original (non-minified) Javascript  == C++ source code


And that's not entirely true, btw, because it depends on what minifier
has been applied. IIRC JSMIN and Packer do not modify the source
(therefore you can always go back to the original JavaScript just by
re-applying whitespace, indendation, etc), while yui-compressor and
Google's do modify the source to remove dead branches, optimize, etc



My proposal:

1. Have multiple versions of JavaScript libraries, very much like we
have multiple versions of binary libraries with soversions, different
package names (libfoo1, libfoo2, etc). We would have libjs-jquery1.4,
libjs-jquery1.6, etc

2. If upstream only provides the original (non-minified) JavaScript,
then we do not have a problem. This never happens, AFAIK.

3. If upstream only provides the minified JavaScript, add the package
for the non-minified JavaScript as a build dependency and re-minify
it. This is what I do in witty, for instance.

4. If upstream provides the original (non-minified) JavaScript *and*
the minified JavaScript, ignore both of them and do same as 3



-- 
Pau Garcia i Quiles
http://www.elpauer.org
(Due to my workload, I may need 10 days to answer)


--
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/CAKcBoksMUmDwC2M=sq-g=v-wtqqlyfxpirtw_kcm6ybrt8q...@mail.gmail.com

Re: Minified files and source code requirement

2011-10-27 Thread Zygmunt Krynicki 

W dniu 27.10.2011 11:22, Pau Garcia i Quiles pisze:


I said this in the original thread and I'll repeat it here: if we have
the non-minified JavaScript, then I see no problem in providing only
the minified version in the binary package.


I'd like to twist this to a different viewpoint. For me as a developer 
having -dev packages with non-minified version would be an awesome 
improvement. Assuming I'm already using the lijs* packages for my work I 
could simply install the -dev packages and flip a switch to use 
non-minified versions and debug my application better.


Best regards
Zygmunt Krynicki


--
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/4ea925a7.1090...@canonical.com

Re: Minified files and source code requirement

2011-10-27 Thread Pau Garcia i Quiles 
On Thu, Oct 27, 2011 at 11:34 AM, Zygmunt Krynicki
 wrote:
> W dniu 27.10.2011 11:22, Pau Garcia i Quiles pisze:
>
>> I said this in the original thread and I'll repeat it here: if we have
>> the non-minified JavaScript, then I see no problem in providing only
>> the minified version in the binary package.
>
> I'd like to twist this to a different viewpoint. For me as a developer
> having -dev packages with non-minified version would be an awesome
> improvement. Assuming I'm already using the lijs* packages for my work I
> could simply install the -dev packages and flip a switch to use non-minified
> versions and debug my application better.

Mmmm interesting, I had not thought about -dev packages. I was talking
about runtime packages all the time.

The main "problem" I see is for many JavaScript libraries the minified
version has a different name (jsquery.min.js vs jquery.js). This would
be easily solvable by using symlinks in most cases, although it is
additional work for the package maintainer.  (in the case of witty, it
is not solvable: a C++ file is generated from the JavaScript source
when building, and there is no .js file to replace on runtime).

-- 
Pau Garcia i Quiles
http://www.elpauer.org
(Due to my workload, I may need 10 days to answer)


-- 
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/cakcboksvwrrkqlwzmyoh_cxpratzzffsotkjso88h2-owcp...@mail.gmail.com

Re: Minified files and source code requirement

2011-10-27 Thread Roland Mas 
Pau Garcia i Quiles, 2011-10-27 11:22:08 +0200 :

> On Thu, Oct 27, 2011 at 10:47 AM, Roland Mas  wrote:
>>> Requiring the non-minified file to be provided in the same source
>>> package is not a very productive use of our time.
>>
>>  Right.  In the same way that providing the source for our binaries
>> isn't very productive, I guess, because who's going to use it when they
>> have the pre-built binaries?  I know this is an exaggeration, but
>> there's no substantial difference between the two cases.
>
> But we provide *source packages*. We do not provide the source in the
> *binary* package.

  Quite true.

> That's what Raphael is talking about: having the minified and the
> original (non-minified) JavaScript in the *same* package (which would
> be the binary package, and also the source package).

  I don't think anyone is actually arguing in favour of shipping the
original JS in the binary packages.  The point being argued is whether
shipping *only* the minified JS in the source package is correct or
not.

> I said this in the original thread and I'll repeat it here: if we have
> the non-minified JavaScript, then I see no problem in providing only
> the minified version in the binary package.

  Agreed, if the minified version is actually generated during the
package build.  If it's not, then we get back to the initial problem.

> To me, these are equivalents:
>
> Minified Javascript == ELF binaries
>
> Original (non-minified) Javascript  == C++ source code
>
>
> And that's not entirely true, btw, because it depends on what minifier
> has been applied. IIRC JSMIN and Packer do not modify the source
> (therefore you can always go back to the original JavaScript just by
> re-applying whitespace, indendation, etc), while yui-compressor and
> Google's do modify the source to remove dead branches, optimize, etc

  The ELF binaries also depend on compiler versions, options and phase
of the moon, so the analogy isn't that wrong.

> My proposal:
>
> 1. Have multiple versions of JavaScript libraries, very much like we
> have multiple versions of binary libraries with soversions, different
> package names (libfoo1, libfoo2, etc). We would have libjs-jquery1.4,
> libjs-jquery1.6, etc
>
> 2. If upstream only provides the original (non-minified) JavaScript,
> then we do not have a problem. This never happens, AFAIK.

  Not quite true; FusionForge upstream in particular ships some complete
versions of some jQuery plugins (FusionForge as a Debian package takes
care to use the system libraries).  But that's a minor point :-)

> 3. If upstream only provides the minified JavaScript, add the package
> for the non-minified JavaScript as a build dependency and re-minify
> it. This is what I do in witty, for instance.
>
> 4. If upstream provides the original (non-minified) JavaScript *and*
> the minified JavaScript, ignore both of them and do same as 3

  This all boils down to "treat Javascript libraries exactly the same as
libraries in other languages", and I'm all in favour of that.

Roland.
-- 
Roland Mas

The best definition of an immortal is someone who hasn't died yet.
  -- in Ye Gods! (Tom Holt)


-- 
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/87aa8m21iz@mirexpress.internal.placard.fr.eu.org

Re: Minified files and source code requirement

2011-10-27 Thread Zygmunt Krynicki 

W dniu 27.10.2011 11:43, Pau Garcia i Quiles pisze:

On Thu, Oct 27, 2011 at 11:34 AM, Zygmunt Krynicki
  wrote:

W dniu 27.10.2011 11:22, Pau Garcia i Quiles pisze:


I said this in the original thread and I'll repeat it here: if we have
the non-minified JavaScript, then I see no problem in providing only
the minified version in the binary package.


I'd like to twist this to a different viewpoint. For me as a developer
having -dev packages with non-minified version would be an awesome
improvement. Assuming I'm already using the lijs* packages for my work I
could simply install the -dev packages and flip a switch to use non-minified
versions and debug my application better.


Mmmm interesting, I had not thought about -dev packages. I was talking
about runtime packages all the time.

The main "problem" I see is for many JavaScript libraries the minified
version has a different name (jsquery.min.js vs jquery.js). This would
be easily solvable by using symlinks in most cases, although it is
additional work for the package maintainer.  (in the case of witty, it
is not solvable: a C++ file is generated from the JavaScript source
when building, and there is no .js file to replace on runtime).



We could use this pattern:

libjsfoo package ships a file that is exposed as 
http://*/javascript/foo/foo.min.js


libjsfoo package ships a file that is exposed as 
http://*/javascript/foo/foo.js


A config option somewhere could allow a developer administering his own 
system to serve foo.js instead of foo.min.js when accesed from the 
/javascript namespace. I guess this could be done in javascript-common.conf


There are no symlinks involved (no maintainer scripts needed), the 
administrator has control over the configuration, -dev packages are 
genuinely useful to developers, non -dev packages are smaller.


Best regards
ZK


--
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/4ea93c00.1040...@canonical.com

Processed: Re: Bug#646795: debian-6.0.3-amd64-gnome-desktop: after used a usb stick to install debian, the usb stick cannot mount automaticly

2011-10-27 Thread Debian Bug Tracking System 
Processing commands for cont...@bugs.debian.org:

> reassign 646795 general
Bug #646795 [debian-6.0.3-amd64-gnome-desktop] 
debian-6.0.3-amd64-gnome-desktop: after used a usb stick to install debian, the 
usb stick cannot mount automaticly
Warning: Unknown package 'debian-6.0.3-amd64-gnome-desktop'
Bug reassigned from package 'debian-6.0.3-amd64-gnome-desktop' to 'general'.
Bug No longer marked as found in versions debian-live.
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
646795: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=646795
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems


-- 
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/handler.s.c.131971458813527.transcr...@bugs.debian.org

Bug#646804: ITP: cheermeup -- Send affirmative messages to the user via the notification library

2011-10-27 Thread Ole Wolf 
Package: wnpp
Severity: wishlist
Owner: Ole Wolf 


* Package name: cheermeup
  Version : 0.5-1
  Upstream Author : Ole Wolf 
* URL : http://debian.blazingangles.net/cheermeup.html
* License : GPLv3
  Programming Lang: Bash script
  Description : Send affirmative messages to the user via the notification 
library

Send an an affirmative message to the currently logged in users via the 
notification library. The affirmative messages are intended to boost the user's 
self-esteem by telling the user he or she is a great person, that someone loves 
him or her, etc.



-- 
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/20111027110315.9502.64020.report...@home.blazingangles.com

Bug#646811: ITP: clooj -- lightweight IDE for clojure

2011-10-27 Thread Mathieu Malaterre 
Package: wnpp
Severity: wishlist
Owner: Mathieu Malaterre 


* Package name: clooj
  Version : 0.2.4
  Upstream Author : Arthur Edelstein
* URL : http://github.com/arthuredelstein/clooj
* License : EPL-1
  Programming Lang: Java
  Description : lightweight IDE for clojure

 clooj is a small, simple IDE (integrated development environment) for the
 clojure programming language, available for free download. clooj is written
 entirely in clojure and uses a swing-based GUI. It is cross-platform, and runs
 as a standalone application or as a clojure editor embedded in another java or
 clojure application.



Package is at:

http://anonscm.debian.org/viewvc/pkg-java/trunk/clooj/



-- 
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/20111027131711.30448.83198.report...@hpdesk.malat.net

Bug#646795: after used a usb stick to install debian, the usb stick cannot mount automaticly

2011-10-27 Thread Laurent Bigonville 
reassign 646795 debian-installer
retitle 646795 debian-installer: after used a usb stick to install debian, the 
usb stick cannot mount automaticly
thanks

Hi,

I get a similar issue after installing a system using an USB key.

It seems that the d-i is adding entries in /etc/fstab for USB key/disks
that prevent udisks to automatically mount USB disks.

I guess that d-i should not add such entries to the fstab.

Cheers

Laurent Bigonville



-- 
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/20111027160118.130e7...@eldamar.bigon.be

Processed: Re: after used a usb stick to install debian, the usb stick cannot mount automaticly

2011-10-27 Thread Debian Bug Tracking System 
Processing commands for cont...@bugs.debian.org:

> reassign 646795 debian-installer
Bug #646795 [general] debian-6.0.3-amd64-gnome-desktop: after used a usb stick 
to install debian, the usb stick cannot mount automaticly
Bug reassigned from package 'general' to 'debian-installer'.
> retitle 646795 debian-installer: after used a usb stick to install debian, 
> the usb stick cannot mount automaticly
Bug #646795 [debian-installer] debian-6.0.3-amd64-gnome-desktop: after used a 
usb stick to install debian, the usb stick cannot mount automaticly
Changed Bug title to 'debian-installer: after used a usb stick to install 
debian, the usb stick cannot mount automaticly' from 
'debian-6.0.3-amd64-gnome-desktop: after used a usb stick to install debian, 
the usb stick cannot mount automaticly'
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
646795: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=646795
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems


-- 
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/handler.s.c.131972408928006.transcr...@bugs.debian.org

Re: Minified files and source code requirement

2011-10-27 Thread Gunnar Wolf 
Zygmunt Krynicki dijo [Thu, Oct 27, 2011 at 01:09:52PM +0200]:
> We could use this pattern:
> 
> libjsfoo package ships a file that is exposed as
> http://*/javascript/foo/foo.min.js
> 
> libjsfoo package ships a file that is exposed as
> http://*/javascript/foo/foo.js
> 
> A config option somewhere could allow a developer administering his
> own system to serve foo.js instead of foo.min.js when accesed from
> the /javascript namespace. I guess this could be done in
> javascript-common.conf
> 
> There are no symlinks involved (no maintainer scripts needed), the
> administrator has control over the configuration, -dev packages are
> genuinely useful to developers, non -dev packages are smaller.

In my case, I have asked some upstreams to ship the un-minified
versions as part of their sources, mainly to satisfy the "prefered
form of modificaiton" GPL clause. (and they have complied so
far). Even if I don't ship the actual (minified or full) version in my
provided packages but just in the source (as I'm depending on the
systemwide library).

But anyway, I don't think we should insist on having both foo.js and
foo.min.js available in the binary packages. Minifying is a way of
compiling, after all. We don't ship source files in our binary
packages unless there is a real reason to do so.


-- 
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/20111027151128.gh11...@gwolf.org

Re: Advocating the use of RDF for Debian's published metadata - Was: Re: Proposal for additional metadata in Debian archives (DEP-11)

2011-10-27 Thread Matthias Klumpp 
Hi!

2011/10/17 Olivier Berger :
> Hi.
>
> I'm not subscribed to ftpmasters, so feel free to CC me in response, and
> I hope d-d@l.d.o is the proper place it will be debated, then (even
> thouh -project already holds some bits too).
Unfortunately, ftpmasters don't have a mailinglist - I hope it is okay
to CC ftpmasters, if this is *not* okay, please write a short mail. -
I haven't got any reply from ftpmasters on this yet.

> Le vendredi 14 octobre 2011 à 19:08 +0200, Matthias Klumpp a écrit :
>
>> AppStream features XML to store metadata. Because we don't use XML
>> somewhere in Debian, DEP-11 features a well-known RFC822-style format.
>
> May I suggest to implement some (standardized) variant of RDF [0] to
> represent this meta-data ?
>
> I think it would help here, to adopt standards for more interoperability
> of Debian's metadata with others'.
> The "package metadata" could even be delivered on the Web of Data
> (Linked Open Data), right from the Debian servers, to allow any
> application to be created, that would consume such metadata.
>
> If RDF/XML (as seems to be proposed by SPDX, to be verified once the
> Linux Foundation site is back) is not suitable, then another format
> would be great as long as it relies on some explicit prefix+suffix
> combination, in order to allow for extensibility, for instance some JSON
> variant of RDF like Turtle [1].
I would like this very much - the proposal is extensible too, but it
also has a few limitations, if someone decides to extend it in futur.
The reason to propose a RFC822-style format for this data is, that
this format is already well-known inside Debian and we have nothing
else using XML yet. Because RFC is already used widely, it should be
easier to implement for ftpmasters.
RDF would work too, as long as it stores the same information as
described in the DEP-11 proposal. (But as far as I can see, it was
designed to do that)

> If a package can both be described with some generic purpose
> "ontology"/standard/schema (for instance the one you envisioned
> initially in DEP 11), and also, depending on context (embedded or
> science, for instance) with another set of metadata (spdx or whatever
> else), you'd be able to mix in the same file, metadata relating to
> different contexts.
This sounds like an overkill to me... Better pick only one format for
that instead of mixing stuff.

> Still, I'm not sure RFC822-style is perfectly compliant with the habit
> of RDF to separate prefix and suffix with a column character ':'. Maybe
> '_' could act as such a separator (must say I haven't checked the RFC
> for allowed tokens in the grammar) ?
We don't have prefix/suffix yet, because we haven't seen a need for it...

> Let's try with an example (btw, the DEP
> http://wiki.debian.org/AppStreamDebianProposal *lacks* examples IMHO) :
Right, maybe I should add one soon :P

> In turtle representation format for RDF, one would have a document that
> looks like this :
>        @prefix rdf: .
>        @prefix dep11: .
>        @prefix debbugs: .
>        @prefix spdx: .
>
>        
>          a dep11:DebianPackage;
>          dep11:application "Iceweasel";
>          dep11:package "iceweasel";
>          spdx:license "MPL-1.1"
>          debbugs:bugs .
>
> (Maybe I didn't understand very well the Application and Package
> meanings in your DEP11 proposal, btw.)
This looks very clean and extensible :) A package is the thing you
install via Synaptic/apt-get/aptitude, while an application is
everything which has a desktop-file and appears in the application
menu. (at least that's how it is defined at time)
A "component" is something a package provides, e.g. a shared library.
E.g. package "libgee2" provides the component "libgee.so.2" of type
shared library. Same applies for Python-modules, Plasma-Engines,
GNOME-Shell extensions etc.

> Anyway, as you can see, here we could have several "domains" of metadata
> sources (ontologies / prefixes) to describe the same package combined in
> a single document.
>
> In RFC822-style, this could be something like :
>
> DEP11_Application: Iceweasel
> DEP11_Package: iceweasel
> spdx_license: MPL-1.1
> debbugs_bugs: http://bugs.debian.org/iceweasel
>
> etc.
>
> But clearly, not reinventing the wheel should be a goal, and adopting
> existing standards for meta-data representation would be my choice, i.e.
> Semantic Web standards (namely RDF).
Agree. Your proposal looks very clean. But again the question is: Do
we want RDF in debian? This is mainly a policy-decision and has
nothing to do with technical details.


> Again, in case you'd doubt it, RDF is just a model, which can be written
> in a number of different formats (not only XML), but the key here is the
> embedded identification of the reference of the ontologies/pref

Re: Bug#646804: ITP: cheermeup -- Send affirmative messages to the user via the notification library

2011-10-27 Thread Steve McIntyre 
Ole Wolf wrote:
>Package: wnpp
>Severity: wishlist
>Owner: Ole Wolf 
>
>
>* Package name: cheermeup
>  Version : 0.5-1
>  Upstream Author : Ole Wolf 
>* URL : http://debian.blazingangles.net/cheermeup.html
>* License : GPLv3
>  Programming Lang: Bash script
>  Description : Send affirmative messages to the user via the notification 
> library
>
>Send an an affirmative message to the currently logged in users via the 
>notification library. The
>affirmative messages are intended to boost the user's self-esteem by telling 
>the user he or she
>is a great person, that someone loves him or her, etc.

Seriously?

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
  Armed with "Valor": "Centurion" represents quality of Discipline,
  Honor, Integrity and Loyalty. Now you don't have to be a Caesar to
  concord the digital world while feeling safe and proud.


-- 
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/e1rjs2z-0003ee...@mail.einval.com

Re: RFC: Additional metadata in Debian archives (DEP-11)

2011-10-27 Thread Matthias Klumpp 
Hi!

2011/10/13 Paul Wise :
>> [...]
>>    Title: AppStream and Component Metadata for Debian
>>    DEP: 11
>>    URL: http://wiki.debian.org/AppStreamDebianProposal
>>    Drivers: Matthias Klumpp ,
>>                Julian Andres Klode ,
>>                Michael Vogt 
>>    Abstract:
>>     Proposal for an additional file in Debian repositories containing
>>     information about components packages provide as well as
>>     all data required for the cross-distro application manager
>>     project AppStream[1].
>
> I would like to point out that some of this stuff is already placed in
> the Packages files. For example gstreamer0.10-ffmpeg has the custom
> Gstreamer-Decoders header containing a list of codecs this package
> supports.
>
> I would like to point out this project:
>
> http://wiki.debian.org/UpstreamMetadata
>
> And strongly suggest that you make your proposal much more general and
> as such able to handle arbitrary upstream metadata, either manually
> added to debian/control by the Debian package maintainer (like
> UpstreamMetadata) or automatically added to debian/foo/DEBIAN/control
> during the build process by automatic tools (presumably as in your
> proposal).
Yes - this was already planned. The only problem at time is that the
"components" data should be distro-agnostic, so if someone requests
the package providing Plasma-Dataengine with name "XYZ" on Debian, it
should also get an usable result on Fedora etc. with that string.
Also, it would be a bit bad to let maintainers define everything they
want, so maybe we should just allow some custom fields like
"DEP11-UpstreamBugtracker".
The UpstreamMetadata approach looks very nice, but it is about general
upstream info. This is not required dor the components part of DEP-11,
but for the application-related part this information will be
extremely valuable.
So maybe we should really add it.
There was also a proposal to use RDF as the format for DEP-11. If we
add much more metadata, an extensible and standardized format like RDF
would be better, IMO. (If ftpmasters allow it)

> I would also like to see the Packages files split up based on audience:
>
> dpkg: package names and relationships
> apt: package download information
> all users: description, homepage etc
> desktop users: freedesktop application info, fontconfig (languages
> etc), gstreamer (codec information), mime types, usb ids, pci ids,
> network protocols
> ...
I'd like that, but I don't think this will happen very soon - this
would require a major restructuring of Debian archives, and
incompatible changes, while DEP-11 is just an optional and less
invasive extension :)

Bye,
  Matthias


--
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/CAKNHny9pAPpqnb4P=zpchojwap5y6ar5brckpfi9ykch-st...@mail.gmail.com

Re: Bug#646804: ITP: cheermeup -- Send affirmative messages to the user via the notification library

2011-10-27 Thread Thomas Thurman 
On Thu, Oct 27, 2011 at 04:38:47PM +0100, Steve McIntyre wrote:
> Ole Wolf wrote:
> >* Package name: cheermeup
> >
> >Send an an affirmative message to the currently logged in users via the 
> >notification library. The
> >affirmative messages are intended to boost the user's self-esteem by telling 
> >the user he or she
> >is a great person, that someone loves him or her, etc.
> 
> Seriously?

In case it helps anyone's decision, I think the list of affirmative messages is 
short enough to
include here:

It is okay to express your needs and feelings.
Someone is thinking about you.
Someone loves you.
You are needed.
You are unique.
You can believe in yourself.
You can trust yourself.
You have a great life.
You have everything you really need.
You have potential.
You look great.
You're a good performer.
You're a great person.
You're a positive person.
You're a strong person.
You're good enough.
You're resourceful.
You're wonderful.
You've made people happy.

T


-- 
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/20111027160756.ga1...@starlight.thurman.org.uk

Re: Minified files and source code requirement

2011-10-27 Thread Russ Allbery 
Roland Mas  writes:
> Raphael Hertzog, 2011-10-27 09:08:37 +0200 :

>> Obfuscated != minified.

>   Intent is all very well, but if the effects of the operation make the
> resulting "code" unusable, even for the best of reasons, then said code
> can't be said to be the source.

I agree with this.  The source has to be something that's in a reasonable
form for a person with appropriate skills to create derivative works.  It
doesn't need to be (in my opinion) identical to the original, but to count
as source it has to still be reasonable to modify it.

Compressing all the whitespace out of it seems fine to me; you can fix
that well enough using an indenter.  If the variables are also rewritten
into meaningless names, I think it becomes more borderline.  If the code
is part "compiled" by, for instance, precomputing significant results or
doing things like turning a yacc parser into the table-driven C code, I
don't think it counts as source any more.

> I thought that the minimal requirements were precisely designed to
> reflect what's needed to do modifications in a sane way, but maybe
> that's just me.

Me too.

-- 
Russ Allbery (r...@debian.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/87aa8m1fuh@windlord.stanford.edu

Re: Bug#646804: ITP: cheermeup -- Send affirmative messages to the user via the notification library

2011-10-27 Thread Enrico Zini 
On Thu, Oct 27, 2011 at 04:07:57PM +, Thomas Thurman wrote:

> In case it helps anyone's decision, I think the list of affirmative messages 
> is short enough to
> include here:
> 
> It is okay to express your needs and feelings.
[...]
> You've made people happy.

WHAT? You mean it doesn't have polygen integration?

How dare they make something like this without using polygen!


Ciao,

Enrico who's SO going to file a bug about it as soon as there is a
bug-reportable package.

-- 
GPG key: 4096R/E7AD5568 2009-05-08 Enrico Zini 


signature.asc
Description: Digital signature

Re: Minified files and source code requirement

2011-10-27 Thread Faidon Liambotis 
On 10/27/11 20:53, Russ Allbery wrote:
> Compressing all the whitespace out of it seems fine to me; you can fix
> that well enough using an indenter.  If the variables are also rewritten
> into meaningless names, I think it becomes more borderline.  If the code
> is part "compiled" by, for instance, precomputing significant results or
> doing things like turning a yacc parser into the table-driven C code, I
> don't think it counts as source any more.

Google's way of "minifiying" javascript, Closure, is actually a
JavaScript to JavaScript compiler: it removes dead code, inlines and
reorders functions and variables, etc.

And of course, there's no easy way of knowing how much content a
minifier has stripped (i.e. if it's a complicated process like Closure,
a simple variable replacement or something in between), which is all the
more of an argument against accepting them without their respective
source.

Regards,
Faidon


-- 
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/20111027184842.ga9...@noc.grnet.gr

Re: Bug#646804: ITP: cheermeup -- Send affirmative messages to the user via the notification library

2011-10-27 Thread Joachim Breitner 
Hi,

Am Donnerstag, den 27.10.2011, 20:43 +0200 schrieb Enrico Zini:
> On Thu, Oct 27, 2011 at 04:07:57PM +, Thomas Thurman wrote:
> > In case it helps anyone's decision, I think the list of affirmative 
> > messages is short enough to
> > include here:
> > 
> > It is okay to express your needs and feelings.
> [...]
> > You've made people happy.
> 
> WHAT? You mean it doesn't have polygen integration?
> 
> How dare they make something like this without using polygen!

And then have
„It is okay to express happy people?“
Cool!

Greetings,
Joachim

-- 
Joachim "nomeata" Breitner
Debian Developer
  nome...@debian.org | ICQ# 74513189 | GPG-Keyid: 4743206C
  JID: nome...@joachim-breitner.de | http://people.debian.org/~nomeata


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

Re: Minified files and source code requirement

2011-10-27 Thread Peter Samuelson 

[Russ Allbery]
> Compressing all the whitespace out of it seems fine to me; you can
> fix that well enough using an indenter.

Yes, but why would _any_ obfuscator, I mean minimizer, compress
whitespace but not remove comments?  The cleverest re-intender in the
world isn't going to be able to restore comments.

Agree with the rest, including your formulation of source as "_a_
reasonable form for modification" in lieu of the classic GPL
definition.


-- 
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/20111027192936.ga2...@p12n.org

Bug#646853: ITP: micromanager -- Microscopy Software

2011-10-27 Thread Mathieu Malaterre 
Package: wnpp
Severity: wishlist
Owner: Mathieu Malaterre 


* Package name: micromanager
  Version : 1.4.6
  Upstream Author : University of California, San Francisco
* URL : http://valelab.ucsf.edu/~MM/MMwiki/index.php/Micro-Manager
* License : GPL
  Programming Lang: Java,C++
  Description : Microscopy Software

 µManager is a software package for control of automated microscopes. It lets
 you execute common microscope image acquisition strategies such as time-lapses,
 multi-channel imaging, z-stacks, and combinations thereof. μManager works with
 microscopes from all four major manufacturers (Leica, Nikon, Olympus and
 Zeiss), most scientific-grade cameras and many peripherals (stages, filter
 wheels, shutters, etc.) used in microscope imaging (check the list of supported
 hardware). Since μManager runs as a plugin to ImageJ, image analysis routines
 are available within the application.
 .
 Unencumbered code provides a GUI for microscope image acquisition, a hardware
 interface layer and hardware interfacing for:
  - ASI stages, filter wheels and shutters
  - Arduino
  - Conix filter changer
  - Velleman K8055 and K8061 digital IO boards
  - Leica DMI microscopes
  - Ludl shutters, stages and filter Wheels
  - Nikon TE2000 microscope
  - Physik Instrumente stages
  - Pecon stage incubators
  - Prior shutters, stages and filter wheels
  - Spectral LMM5 laser controller
  - Sutter shutters, filter wheels and DG4
  - Vincent Uniblitz shutters
  - Yokogawa spinning disk confocal CSU22 and CSUX
  - Zeiss microscopes (two 'generations')
  - iidc1394 compatible cameras (through libdc1394)



-- 
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/20111027202225.1750.10398.report...@hpdesk.malat.net

Re: Bug#646804: ITP: cheermeup -- Send affirmative messages to the user via the notification library

2011-10-27 Thread Andrea Bolognani 
On Thu, Oct 27, 2011 at 09:28:05PM +0200, Joachim Breitner wrote:

> > WHAT? You mean it doesn't have polygen integration?
> > 
> > How dare they make something like this without using polygen!
> 
> And then have
> „It is okay to express happy people?“
> Cool!

This (and the parent message) made my day.
Please make this an actual polygen grammar!

-- 
Andrea Bolognani 
Resistance is futile, you will be garbage collected.


signature.asc
Description: Digital signature

Re: Minified files and source code requirement

2011-10-27 Thread Philipp Kern 
On 2011-10-27, Russ Allbery  wrote:
> In other words, given the haziness in this area and the wildly divergent
> practices of people when creating non-code works, I think we should look
> at whether the provided "source" provides reasonable opportunity to meet
> the core definition of free software, namely the ability to study and
> adopt the work for one's own purposes and republish one's modifications,
> and not get too hung up on whether the exact tools and steps the original
> author took are included.

What about a game that provides a set of resource source files but no scripts
to create the actual pngs and jpegs?  As long as you just the tools (Blender,
Gimp and such, Ogre 3D tools) you can sort of get the original dump out.

As long as I ship those resources unused as a separate orig tarball, would
that be acceptable enough for inclusion into Debian?  They are actually
in a separate repository, but it does get tagged for releases.

(And yes, that's a real-world example[0].  I asked some people, pabs among
them, on #-games some months ago, and the consensus seemed to be that
everything needs to be regeneratable by scripts.  The license in question
is ISC, not GPL.)

Kind regards
Philipp Kern

[0] https://launchpad.net/~openclonkdevteam/+archive/release


-- 
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/slrnjajn4g.es3.tr...@kelgar.0x539.de

Re: Minified files and source code requirement

2011-10-27 Thread Russ Allbery 
Philipp Kern  writes:
> On 2011-10-27, Russ Allbery  wrote:

>> In other words, given the haziness in this area and the wildly
>> divergent practices of people when creating non-code works, I think we
>> should look at whether the provided "source" provides reasonable
>> opportunity to meet the core definition of free software, namely the
>> ability to study and adopt the work for one's own purposes and
>> republish one's modifications, and not get too hung up on whether the
>> exact tools and steps the original author took are included.

> What about a game that provides a set of resource source files but no
> scripts to create the actual pngs and jpegs?  As long as you just the
> tools (Blender, Gimp and such, Ogre 3D tools) you can sort of get the
> original dump out.

I don't think there's an immediately obvious answer.  To me, it depends on
what someone who wanted to modify the game resources would need in order
to do so.  Do you think that someone who was generating a modified copy of
the game would have available to them all the resources they need to do
that?

> As long as I ship those resources unused as a separate orig tarball,
> would that be acceptable enough for inclusion into Debian?

As long as it's reasonable to expect someone modifying the game to use
just the resources provided in the tarball, and they don't need anything
else to be able to make modifications, I think so.

The way I look at it is that the desire to build everything automatically
from source is, in essence, a test suite.  It's basically a test that the
source *is* the source.  It's a valuable test, and I like tests, and by
all means we should run tests where possible.  I don't ever want to
discourage people from running tests.  But I think it is a test, not a
requirement, and Debian doesn't *require* that software test suites be run
as part of our standard build if there's some difficulty in doing so.

If those source files can't be used to generate the resources, that's a
bug, and if you don't build the resources from the source files, it's a
bug that you may not notice.  Like any other missing test, it increases
the chance that Debian will ship buggy packages.  But just as Debian
doesn't require that all package functionality be covered by a test suite,
I don't think Debian should require that this be covered by a test suite.

Where it's possible to test this, such as regenerating the Autotools
files, or where there are obvious problems in using pregenerated files,
such as the clear and obvious problems with using pre-built ELF binaries,
I'm all in favor of requiring the package build from source in those ways.
But game resources are an example where I think this can be more trouble
than it's actually worth if upstream is uninterested in doing that work
and upstream themselves uses a manual process to generate the data that's
used at runtime for the game.

-- 
Russ Allbery (r...@debian.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/87lis6xd2i@windlord.stanford.edu

Work-needing packages report for Oct 28, 2011

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

Total number of orphaned packages: 398 (new: 5)
Total number of packages offered up for adoption: 144 (new: 2)
Total number of packages requested help for: 65 (new: 1)

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



The following packages have been orphaned:

   fillmore-lombard (#646404), orphaned 4 days ago
 Description: multitrack audio recorder and video editor
 Installations reported by Popcon: 19

   klone (#646214), orphaned 5 days ago
 Reverse Depends: klone-package
 Installations reported by Popcon: 14

   libvisual (#646655), orphaned yesterday
 Description: Audio visualization framework
 Reverse Depends: gstreamer0.10-plugins-base libgmerlin0
   libvisual-0.4-dev libvisual-0.4-plugins libvisual-projectm
   xmms2-client-vis
 Installations reported by Popcon: 56948

   pdksh (#646382), orphaned 4 days ago
 Description: A public domain version of the Korn shell
 Reverse Depends: flowscan
 Installations reported by Popcon: 1615

   vbrfix (#646384), orphaned 4 days ago
 Description: corrects MP3 files that have incorrect VBR information
 Installations reported by Popcon: 135

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



The following packages have been given up for adoption:

   preload (#646216), offered 5 days ago
 Installations reported by Popcon: 1081

   qtpfsgui (#646315), offered 4 days ago
 Description: graphical user interface providing a workflow for HDR
   imaging
 Installations reported by Popcon: 605

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



For the following packages help is requested:

[NEW] apache2 (#646208), requested 5 days ago
 Description: Apache HTTP Server
 Reverse Depends: aegis-web apache2 apache2-dbg apache2-mpm-event
   apache2-mpm-itk apache2-mpm-prefork apache2-mpm-worker
   apache2-prefork-dev apache2-suexec apache2-suexec-custom (179 more
   omitted)
 Installations reported by Popcon: 59015

   apt-xapian-index (#567955), requested 633 days ago
 Description: maintenance tools for a Xapian index of Debian packages
 Reverse Depends: adept ept-cache fuss-launcher packagesearch
 Installations reported by Popcon: 46817

   ara (#450876), requested 1446 days ago
 Description: utility for searching the Debian package database
 Installations reported by Popcon: 116

   asymptote (#517342), requested 972 days ago
 Description: script-based vector graphics language inspired by
   MetaPost
 Installations reported by Popcon: 2802

   athcool (#278442), requested 2557 days ago
 Description: Enable powersaving mode for Athlon/Duron processors
 Installations reported by Popcon: 101

   balsa (#642906), requested 32 days ago
 Description: An e-mail client for GNOME
 Reverse Depends: balsa-dbg debreaper
 Installations reported by Popcon: 279

   bastille (#592137), requested 446 days ago
 Description: Security hardening tool
 Installations reported by Popcon: 286

   boinc (#511243), requested 1022 days ago
 Description: BOINC distributed computing
 Reverse Depends: boinc boinc-app-milkyway boinc-app-seti boinc-dbg
   boinc-server-maker
 Installations reported by Popcon: 1874

   cardstories (#624100), requested 185 days ago
 Description: Find out a card using a sentence made up by another
   player
 Installations reported by Popcon: 5

   chromium-browser (#583826), requested 515 days ago
 Description: Chromium browser
 Reverse Depends: chromium chromium-browser chromium-browser-dbg
   chromium-browser-inspector chromium-browser-l10n chromium-dbg
   chromium-l10n gecko-mediaplayer mozplugger
 Installations reported by Popcon: 9112

   cryptsetup (#600777), requested 372 days ago
 Description: configures encrypted block devices
 Reverse Depends: cryptsetup cryptsetup-udeb libcryptsetup-dev
   libguestfs0 libpam-mount ltsp-client mandos-client partman-crypto-dm
   rescue-mode systemd
 Installations reported by Popcon: 6865

   cvs (#354176), requested 2072 days ago
 Description: Concurrent Versions System
 Reverse Depends: cvs-autoreleasedeb cvs-buildpackage cvs2cl cvs2html
   cvschangelogbuilder cvsconnect cvsd cvsps cvsservice cvssuck (8 more
   omitted)
 Installations reported by Popcon: 18228

   dctrl-tools (#448284), requested 1461 days ago
 Description: Command-line tools to pr

Bug#646876: ITP: libpaint-ruby -- terminal paint library with 256 color and effect support

2011-10-27 Thread chrysn 
Package: wnpp
Severity: wishlist
Owner: chrysn 

* Package name: libpaint-ruby
  Version : 0.8.3
  Upstream Author : Jan Lelis 
* URL : http://rubygems.org/gems/paint
* License : MIT
  Programming Lang: Ruby
  Description : terminal paint library with 256 color and effect support

 The paint library for ruby provides a single method, `Paint.[]`, that produces
 colored output on terminals. It comes with support for 256 color terminals,
 ANSI effects, and allows defining custom shortcuts.

this library is a dependency of lolcat (itp will follow); i have no
other interest in the library itself.

i am not familiar with Ruby as a language, neither with ruby packaging.
my current packaging approach is to just dump the lib/ files into
/usr/lib/ruby/1.8/ (as it is done in libtrollop), but that might not be
best practice. also, i completely ignore the spec/ directory, which
might be needed for online documentation (?; i'm more familiar with
python, where we have dh_python2 and docstrings in the source).

in general, the package is lintian clean. i'm far from confident
everything is packaged the right way, but it works and has nothing fancy
to it that could break anything -- some positive feedback from someone
who can judge the ruby side of it provided, i'd ask for a sponsor.

the packages will be available on debian mentors in a few minutes.


signature.asc
Description: Digital signature

Bug#646877: ITP: lolcat -- colorful `cat`

2011-10-27 Thread chrysn 
Package: wnpp
Severity: wishlist
Owner: chrysn 

* Package name: lolcat
  Version : 42.0.99-1
  Upstream Author : Moe 
* URL : https://github.com/busyloop/lolcat
* License : WTFPL
  Programming Lang: Ruby
  Description : colorful `cat`

 lolcat concatenates files like the UNIX `cat` program, but colors it for the
 lulz in a rainbow animation. Terminals with 256 colors and animations are
 supported.

lolcat is a typical "game" program in the sense of cowsay or fortune;
the kind of tool you keep installed for occasional amuesement.

i'm not familiar with Ruby or ruby packaging; the current packaging just
dumps the lib/ files in /usr/lib/ruby/1.8/ and installs the executable
script to /usr/games/. if there is a better way to install gems
(ideally one that doesn't involve cdbs, just as a matter of personal
preference), please let me know.

the package is lintian clean (except for the pedantic issue of not
having an upstream changelog), and works well. if someone could confirm
that the ruby packaging part is sound, i'd be looking for a sponsor.

the packages will be available on debian mentors in a few minutes.


signature.asc
Description: Digital signature

Re: Failed to make a .deb package of PECL uploadprogress on squeeze. Any solution?

2011-10-27 Thread Jaisen 
Hello...,

Please help..,
I need to make this.
I feel bad that, nobody in this list paying no attention in this.. :(


2011/10/27 Jaisen :
> Hi,
>
> I was trying to make a .deb package of uploadprogress-1.0.3.1.tgz,
> (downloaded from PECL - http://pecl.php.net/package/uploadprogress)
> using dh-make-php, on Squeeze.
>
> Followed the instructions given in the link:
> http://freestylesystems.co.uk/blog/installing-pecl-uploadprogress-extension-drupal-filefield-30-module#install-unix
>
> I stuck in the middle, as it need both php5-dev and php4-dev.
> But there is no php4-dev in squeeze repo.
>
> What I have done is pasted below.
>
> As I am new to make a .deb package, I don't know how to resolve this. Any way?
>
>
> --
> $sudo apt-get install dh-make-php
>        Reading package lists... Done
>        Building dependency tree
>        Reading state information... Done
>        dh-make-php is already the newest version.
>        0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
> $pecl download uploadprogress
>        downloading uploadprogress-1.0.3.1.tgz ...
>        Starting to download uploadprogress-1.0.3.1.tgz (9,040 bytes)
>        .done: 9,040 bytes
>        File /home/jaisen/drupal/uploadprogress-1.0.3.1.tgz downloaded
> $cd drupal/
> $dh-make-pecl uploadprogress-1.0.3.1.tgz
>        PHP Notice:  Undefined index: date in
> /usr/share/dh-make-php/phppkginfo on line 60
>        PHP Notice:  Undefined index: date in
> /usr/share/dh-make-php/phppkginfo on line 60
>        Creating debian source package: php-uploadprogress-1.0.3.1
>        Upstream is: Christian Stocker, Ben Ramsey
>        Guessing Maintainer: jaisen 
> $ cd php-uploadprogress-1.0.3.1/
> $ fakeroot dpkg-buildpackage -b
>        dpkg-buildpackage: export CFLAGS from dpkg-buildflags (origin:
> vendor): -g -O2
>        dpkg-buildpackage: export CPPFLAGS from dpkg-buildflags
> (origin: vendor):
>        dpkg-buildpackage: export CXXFLAGS from dpkg-buildflags
> (origin: vendor): -g -O2
>        dpkg-buildpackage: export FFLAGS from dpkg-buildflags (origin:
> vendor): -g -O2
>        dpkg-buildpackage: export LDFLAGS from dpkg-buildflags (origin: 
> vendor):
>        dpkg-buildpackage: source package php-uploadprogress
>        dpkg-buildpackage: source version 1.0.3.1-1
>        dpkg-buildpackage: source changed by jaisen 
>        dpkg-buildpackage: host architecture i386
>        dpkg-source --before-build php-uploadprogress-1.0.3.1
>        dpkg-checkbuilddeps: Unmet build dependencies: php4-dev
>        dpkg-buildpackage: warning: Build dependencies/conflicts
> unsatisfied; aborting.
>        dpkg-buildpackage: warning: (Use -d flag to override.)
> $ fakeroot dpkg-buildpackage -d
>        dpkg-buildpackage: export CFLAGS from dpkg-buildflags (origin: 
> vendor): -g -O2
>        dpkg-buildpackage: export CPPFLAGS from dpkg-buildflags (origin: 
> vendor):
>        dpkg-buildpackage: export CXXFLAGS from dpkg-buildflags (origin:
> vendor): -g -O2
>        dpkg-buildpackage: export FFLAGS from dpkg-buildflags (origin: 
> vendor): -g -O2
>        dpkg-buildpackage: export LDFLAGS from dpkg-buildflags (origin: 
> vendor):
>        dpkg-buildpackage: source package php-uploadprogress
>        dpkg-buildpackage: source version 1.0.3.1-1
>        dpkg-buildpackage: source changed by jaisen 
>        dpkg-buildpackage: host architecture i386
>         dpkg-source --before-build php-uploadprogress-1.0.3.1
>         debian/rules clean
>        dh_testdir
>        dh_testroot
>        rm -f build-stamp* configure-stamp*
>        # Add here commands to clean up after the build process.
>        (cd uploadprogress-1.0.3.1; \
>                        /usr/bin/make clean; \
>                        /usr/bin/phpize4 --clean)
>        make[1]: Entering directory
> `/home/jaisen/drupal/php-uploadprogress-1.0.3.1/uploadprogress-1.0.3.1'
>        make[1]: *** No rule to make target `clean'.  Stop.
>        make[1]: Leaving directory
> `/home/jaisen/drupal/php-uploadprogress-1.0.3.1/uploadprogress-1.0.3.1'
>        /bin/sh: /usr/bin/phpize4: not found
>        make: *** [clean-v4] Error 127
>        dpkg-buildpackage: error: debian/rules clean gave error exit status 2
> $
>



-- 
~-~-~-~-~-~-~-~-~-~-~-~-~-~-~
- നെടുമ്പാല ജയ്സെന്‍ -
~-~-~-~-~-~-~-~-~-~-~-~-~-~-~
    (`'·.¸(`'·.¸^¸.·'´)¸.·'´)
«´¨`·* .  Jaisen . *..´¨`»
    (¸.·'´(`'·.¸ ¸.·'´)`'·.¸)
    ¸.·´^.`'·.¸ ¸.·'´
     ( `·.¸`·.¸
      `·.¸ )`·.¸
     ¸.·(´ `·.¸
    ¸.·(.·´)`·.¸
      ( `v´ )
        `v´


--
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/CAKnL01-bALyn_WvVAwZXUz3eExtPctqLR+Z+=jsb33mky6e...@mail.gmail.com

Re: Failed to make a .deb package of PECL uploadprogress on squeeze. Any solution?

2011-10-27 Thread Uwe Steinmann 
On Fri, Oct 28, 2011 at 07:28:09AM +0530, Jaisen wrote:
> Hello...,
> 
> Please help..,
> I need to make this.
> I feel bad that, nobody in this list paying no attention in this.. :(

Try the '--only 5' option of dh-make-pecl

  Uwe

-- 
  MMK GmbH, Fleyer Str. 196, 58097 Hagen
  uwe.steinm...@mmk-hagen.de
  Tel: 02331 840446Fax: 02331 843920


signature.asc
Description: Digital signature