Re: Enabling uscan to simply remove files from upstream source

2012-08-22 Thread Jonas Smedegaard 
On 12-08-22 at 09:39am, Paul Wise wrote:
> On Tue, Aug 21, 2012 at 6:21 PM, Andreas Tille wrote:
> 
> > Any further hints / remarks?
> 
> In comparison to the current method for repacking (debian/rules
> get-orig-source), this doesn't allow per-file-set comments about why
> the file-set is being removed. I often use this to document in more
> detail why I am removing files. So I view this spec as a downgrade
> from what we have now.

Good point.

Copyright file format 1.0 allows multiple paragraphs of same name.

So would be nice to check that the implementation properly includes all 
of the following items:

Format: 
 http://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
Source: http://susy.oddbird.net/
  Repackaged, excluding non-DFSG licensed fonts and source-less
  JavaScript
Files-Excluded:
  docs/source/javascripts/jquery-1.7.1.min.js
  docs/source/javascripts/modernizr-2.5.3.min.js
Files-Excluded-comment: Exlude source-less JavaScript
Files-Excluded: foo/bar
  docs/source/fonts/*
  baz
  boom/boom/
Files-Excluded-comment: Exlude non-DFSG licensed fonts and more
 Just for demonstration purpose, this paragraph has multiple
 lines.


 - Jonas

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

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


signature.asc
Description: Digital signature

Re: Enabling uscan to simply remove files from upstream source

2012-08-22 Thread Jonas Smedegaard 
On 12-08-21 at 12:21pm, Andreas Tille wrote:
> Regarding the implementation there was some uncertainity about the 
> actual Perl module to use.  In the attached example script I decided 
> to stick to Dpkg::Control and left the code for Parse::DebControl as a 
> comment which could pretty easily could replace the other parser.

Do Dpkg::Control::Hash provide the equivalent of flags discardCase and 
singleBlock for Parse::DebControl, or are those considered unimportant?

As I recall, Copyright Format 1.0 is enabled by its identifying Format: 
line being the first line of the file, and my proposal is for 
Files-Excluded lines to be in that same section (and only there).  Also, 
I seem to recall during the development of the format that it should be 
ok to add non-machine-readable chunks _after_ the machine-readable 
parts.  That's why I found it quite compelling to me that those two 
flags existed in Parse::DebControl: You don't accidentally (although 
arguably quite rare) pickup unintended hints further down the file.


 - Jonas

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

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


signature.asc
Description: Digital signature

Re: Bug#684396: ITP: openrc -- alternative boot mechanism that manages the services, startup and shutdown of a host

2012-08-22 Thread Philipp Kern 
On Mon, Aug 20, 2012 at 12:37:32PM -0700, Russ Allbery wrote:
> We don't have a particularly good way of handling this situation right now
> other than one-off work on each package that may need to be treated
> unusually.  It's a bit difficult for the maintainer to determine the
> implications for the dependency graph, and there isn't any good way to
> exclude all packages in a particular class from a particular architecture.

It's not that hard. Something like «dak rm -n -R -b -a s390 -s unstable
pciutils libpci3» on ries (the DD-accessible ftp-master mirror). However
this does not recurse, so you need to add the resulting packages to the RM
or look if those listed can be fixed by dropping the Build-Dependency.

> We have some architectures where I really doubt that anyone is using them
> for anything other than a server (s390, for instance), and (modulo cases
> where it makes sense to run such software as part of a remote session on a
> shared-user system) [...]

People once said exactly that as a use case. However I'm unsure who the
users of Debian s390(x) really are. And I don't know if the largest user
(still?) does that. I imagine that it would work to use a mainframe as a
thin client host in any case.

Some blacklisting happens in P-a-s and some through BD-Uninstallable by
Build-Depending on something that does not exist on that architecture.

Kind regards
Philipp Kern


signature.asc
Description: Digital signature

Re: Minified javascript files

2012-08-22 Thread Thomas Goirand 
[About yui-compressor]

On 08/21/2012 02:49 AM, Vincent Bernat wrote:
> It is not used anymore and is therefore less tested and less
> trustworthy.
>   

Sorry for the dumb questions (which are kind of conflicting each
other btw), but:
- If the only problem is testing, can't it be tested, so we know?
- If it's not trustworthy, why should it stay in Debian?

Cheers,

Thomas


-- 
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/5034bc6f.6080...@debian.org

Re: Minified javascript files

2012-08-22 Thread Igor Pashev 
20.08.2012 11:33, Thomas Goirand пишет:
> So, could you tell in what way yui-compressor isn't considered
> not reliable enough? Does it crash? Or does it produce bad
> minified scripts? In which case: in what way bad?

yui-compressor has a lot of dependencies :-)


-- 
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/5034cdb4.8010...@gmail.com

Re: Minified javascript files

2012-08-22 Thread Damien Raude-Morvan 

Hi,

/me put on his yui-compressor maintainer hat ;)

Le 22/08/2012 13:03, Thomas Goirand a écrit :

[About yui-compressor]

On 08/21/2012 02:49 AM, Vincent Bernat wrote:

It is not used anymore and is therefore less tested and less
trustworthy.



Sorry for the dumb questions (which are kind of conflicting each
other btw), but:
- If the only problem is testing, can't it be tested, so we know?
- If it's not trustworthy, why should it stay in Debian?


IMHO, it's obvious that yui-compressor is not - anymore - the most 
efficient javascript minifier and better alternative exists. It's simply 
not used anymore by "big players" of Javascript libs (like jQuery) so it 
receives less attention (even from Yahoo for YUI).


But I disagree on "trustworthy" argument :
- yui-compressor have been used for years for javascript compression 
(way before closure-compiler or uglifyjs) so it can't be *that* bad
- as casual user of yui-compressor, I have hardly seen failure to 
correctly minify javascript file

- in Debian, I haven't received a bug report about any corner case

So, from my point of view, it seems that we can at least try use it as a 
alterntive minifier of upstream official is not available in Debian.


my 2 cents,


--
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/5034d333.5060...@drazzib.com

Re: can we (fully) release-goal decommissioning of trolls

2012-08-22 Thread Christoph Anton Mitterer 
On Tue, 2012-08-21 at 00:47 +0200, Josselin Mouette wrote:
> Thanks for this excellent example of the behavior I described.  With
> “down to Windows level” you must think you have hit the trigger of the
> ultimate bazooka to shut people up, don’t you?
Well Josselin,... I'm not generally against new technologies (like
PolicyKit, CK, and all the "uoptia" stuff) but I guess no one can
deny the following:

- Some of these get deprecated in a yearly fashion (HAL, DeviceKit, and
not apparently ConsoleKit)... which is IMHO quite bad for developers
using this stuff.

- Some of them have quite some severe bugs; I remember one where (was it
DeviceKit or udisks?) the dm-crypt keys of encrypted volumes were
exported to the user...
(Of course, other software has bugs, too.)

- Most of them are difficult to understand. Take PolicyKit. I'm sure you
can do a lot with it, but also, that most People just don't know how.
Partially that is definitely a documentation problem, partially of
course also, that users tend to refuse to learn new things.


And with respect to what Stefan wrote:
- I think that many of these new technologies have at least a default
config that is written from a desktop computers point of view.
Which often means that settings are in a way, that people with strong
security in mind won't like it.
Even if, by default, it just allows you to connect to any network.

Similar (security) problems are (possibly) brought by techniques like
Avahi...


I guess that what people in these kind of discussion mean sometimes when
comparing the stuff to Windows/Apple.


Cheers,
Chris.


smime.p7s
Description: S/MIME cryptographic signature

Re: Minified javascript files

2012-08-22 Thread Damien Raude-Morvan 

Le 22/08/2012 14:52, Simon Josefsson a écrit :

Damien Raude-Morvan  writes:


IMHO, it's obvious that yui-compressor is not - anymore - the most
efficient javascript minifier and better alternative exists. It's
simply not used anymore by "big players" of Javascript libs (like
jQuery) so it receives less attention (even from Yahoo for YUI).


What is upstream jQuery using?  Is it free software?


Please, try to read all posts in thread before posting a question... it 
has already been explained.


jQuery now use Grunt as "build system". It's grunt who automatically 
lint files with JSLint and minify files with UglifyJS [1].


UglifyJS is under BSD licence and, AFAIK, is already packaged for Debian 
but blocked by freeze of nodejs package :

http://bugs.debian.org/684044

[1] https://github.com/mishoo/UglifyJS/


--
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/5034d971.4050...@drazzib.com

Re: Minified javascript files

2012-08-22 Thread Simon Josefsson 
Damien Raude-Morvan  writes:

> IMHO, it's obvious that yui-compressor is not - anymore - the most
> efficient javascript minifier and better alternative exists. It's
> simply not used anymore by "big players" of Javascript libs (like
> jQuery) so it receives less attention (even from Yahoo for YUI).

What is upstream jQuery using?  Is it free software?

/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/87d32jay22@latte.josefsson.org

Re: bugs opened upstream (was: can we (fully) fix/integrate NetworkManager (preferred) or release-goal its decommissioning)

2012-08-22 Thread Christoph Anton Mitterer 
On Mon, 2012-08-20 at 13:08 +0200, Bjørn Mork wrote:
> Debian need *both*, and any efforts in this area should be put into
> making them interoperate.
That's my point! :-)

So for the curious amongst you... I've opened the following
ifupdown-plugin related bugs/improvement-ideas upstream:
https://bugzilla.gnome.org/show_bug.cgi?id=682375
https://bugzilla.gnome.org/show_bug.cgi?id=682377
https://bugzilla.gnome.org/show_bug.cgi?id=682406
https://bugzilla.gnome.org/show_bug.cgi?id=682407
https://bugzilla.gnome.org/show_bug.cgi?id=682408
https://bugzilla.gnome.org/show_bug.cgi?id=682409


All of them are "small" isolated problems or enhancement ideas, towards
better integration with ifupdown.


Further bugs for better integration with other native tools, I've opened
include:
https://bugzilla.gnome.org/show_bug.cgi?id=681666
https://bugzilla.gnome.org/show_bug.cgi?id=681667
http://wiki.strongswan.org/issues/215


There was also some discussion between me and upstream at the now
closed:
https://bugzilla.gnome.org/show_bug.cgi?id=681668
Most of the issues I describe there, are now split out in the bugs
above.


I'm not sure whether for myself will find time to work on any of these
(especially as I'd have to read into the NM code at first)... but
perhaps some of our NM experts here will find the one or the other worth
and "trivial" to fix/implement ;)


Cheers,
Chris.


smime.p7s
Description: S/MIME cryptographic signature

Re: can we (fully) release-goal decommissioning of trolls

2012-08-22 Thread Christoph Anton Mitterer 
On Mon, 2012-08-20 at 12:38 +0200, Josselin Mouette wrote:
> This is untrue. Any *physically logged on* user can connect to any
> network. For a desktop system this is clearly a reasonable default
Well the are people that may disagree here. Of course this is dependent
on personal views.
Anyway what _I_ meant is now described and reported now in
https://bugzilla.gnome.org/show_bug.cgi?id=682406 . :)

And yes, I know, it's already an issue when managed mode was enabled.


> This is a reasonable choice, given that most distros have very basic or
> nonexistent network configuration (/etc/sysconfig/network-scripts
> hahaha) and those who have a decent one were not designed for high level
> integration.
Uhm... yeah well,... I personally don't think so,.. because distros (I
guess including Debian), will continue to have and user their own
"native" tools... whether they're perfect or not.
(And I agree with your laughter on /etc/sysconfig/network* ;-) )


> > 3) ifupdown integration is really bad
> Which is why it is disabled by default. Not that it hurts much.
People who want to continue using /e/n/i will have to enable it, or it won't 
work at all... or do I miss something?
And IMHO it's invalid to demand that people should drop their use of a
well proven system.


> If you want to fix this broken set of features that is not enabled by
> default, send patches.
I'm currently not to inclined in getting into NM development... and I
guess it's not forbidden to discuss / report bugs or ideas for
enhancements... when one is not part of the developers, is it? ;)


> > c) when NM is running, I cannot use ifup foo / ifdown foo / ifconfig
> > ... well I can.. but then everything gets really messed up
> 
> So what? What actual problem does it cause?
E.g. scripts using them automatically don't work any longer.
Consider something like a cron script, that needs to connect to some VPN
and transmit periodically collected data.


> > 4) upstream more or less doesn't want to support these scenarios...
> 
> Of course, because *as you pointed out yourself*, the idea of parsing
> system configuration is stupid and leads to bugs.
Yes but I haven't said, that this parsing wouldn't be needed to be
replaced by directly using the native tools...


> Yes. This is actually what happens on usual setups (one interface, DHCP
> without any special options) upon NM installation.
But you know, that not all debian installations need to be simple laptop
installations, don't you? And even laptop installations can do more
complex things (take my example from above).


> I think the disease mostly consists in old farts
Wow,... very adult to insult people...

> These people are the disease.
Jep... very adult...


Chris.


smime.p7s
Description: S/MIME cryptographic signature

Re: can we (fully) release-goal decommissioning of trolls

2012-08-22 Thread Philipp Kern 
On Wed, Aug 22, 2012 at 03:03:29PM +0200, Christoph Anton Mitterer wrote:
> Similar (security) problems are (possibly) brought by techniques like
> Avahi...

There's not much revealed by it that's not visible from a port scan. (Ok, the
hostname probably.) And the mDNS data stream is only accessible from the same
broadcast domain while the announced port itself will be open to the public.

Kind regards
Philipp Kern


signature.asc
Description: Digital signature

Re: Minified javascript files

2012-08-22 Thread Bernd Zeimetz 
On 08/17/2012 10:21 PM, Raphael Hertzog wrote:
> Hi,
> 
> On Fri, 17 Aug 2012, Luca Falavigna wrote:
>> 2012/8/17 Bernd Zeimetz :
>>> But it usually does and also results in a source tarball which is
>>> missing essential pieces of the software, so people who download it for
>>> non-Debian usage will fail to run the shipped source just because we
>>> removed an otherwise free piece of software.
>>
>> This does not make sense if the removed pieces are useless, as the
>> core of this discussion is about.
> 
> They are not useless if you take the pristine source which is the
> situation that was described by Bernd. When we remove files we often have
> to do supplementary modifications (debian/patches/ or add symlink at the
> proper place) to get the software to work again... for example changing
> the path where the libraries are expected to be found.

Also please remember the Social Contract:
Our priorities are our users and free software.

If I would remove an otherwise free piece of software I'm not using in
the binary package just because the original, non-minified version of it
is missing, I think that I would violate the SC. If the opinion of the
ftp-masters is different from mine I think we might need a GR to solve
this issue.

-- 
 Bernd ZeimetzDebian GNU/Linux Developer
 http://bzed.dehttp://www.debian.org
 GPG Fingerprint: ECA1 E3F2 8E11 2432 D485  DD95 EB36 171A 6FF9 435F


-- 
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/5034e837.4050...@bzed.de

Processed: Re: Bug#659831: python2.7: When python2.7 is default, some python based programs don't work because of ImportError.

2012-08-22 Thread Debian Bug Tracking System 
Processing commands for cont...@bugs.debian.org:

> reassign 659831 general
Bug #659831 [python2.7] python2.7: When python2.7 is default, some python based 
programs don't work because of ImportError.
Bug reassigned from package 'python2.7' to 'general'.
No longer marked as found in versions python2.7/2.7.2-13.
Ignoring request to alter fixed versions of bug #659831 to the same values 
previously set
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
659831: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=659831
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.134565481729295.transcr...@bugs.debian.org

Re: Minified javascript files

2012-08-22 Thread Thomas Goirand 
On 08/22/2012 10:09 PM, Bernd Zeimetz wrote:
> Also please remember the Social Contract:
> Our priorities are our users and free software.
>
> If I would remove an otherwise free piece of software I'm not using in
> the binary package just because the original, non-minified version of it
> is missing, I think that I would violate the SC.
Did you miss the word *free* in "free software"?
It's actually a quite important word... ;)

I'm afraid I don't agree with your reading of the SC.
I believe we want the *full* source code of what we release.

While I can agree that removing the minified version of a
javascript script from the original source might be seen
as (arguably) a little bit extreme and annoying (but I do
respect this view), I really think we *do* need the normal
non-minified version of every script and build from that.

I don't think anyone else has argued otherwise in this
thread (please correct me if I'm wrong here...), we have
only been discussing removing the minified version from
the original sources only (but didn't discuss the fact
the non-minified version should be there *always*).

Cheers,

Thomas


-- 
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/5035208c.2070...@debian.org

Re: Minified javascript files

2012-08-22 Thread Russ Allbery 
Thomas Goirand  writes:

> While I can agree that removing the minified version of a javascript
> script from the original source might be seen as (arguably) a little bit
> extreme and annoying (but I do respect this view), I really think we
> *do* need the normal non-minified version of every script and build from
> that.

> I don't think anyone else has argued otherwise in this thread (please
> correct me if I'm wrong here...), we have only been discussing removing
> the minified version from the original sources only (but didn't discuss
> the fact the non-minified version should be there *always*).

I think the debate in this thread is about whether it makes sense to
require removing the minimized version from the upstream source when we
don't install that file or otherwise use it in the binary package (because
the binary package depends on the separately-packaged version of the same
Javascript library, which already has both the minimized and non-minimized
version and fully satisfies the DFSG).

-- 
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/87obm27pan@windlord.stanford.edu

Bug#685641: ITP: xul-ext-reloadevery -- Reload web pages in regular intervals

2012-08-22 Thread Mike Gabriel 
Package: wnpp
Severity: wishlist
Owner: Mike Gabriel 

* Package name: xul-ext-reloadevery
  Version : 13.0.0
  Upstream Author : Jaap Haitsma 
* URL : http://reloadevery.mozdev.org
* License : MPL-1.1
  Programming Lang: Mozilla/XUL Extension
  Description : Reload web pages in regular intervals

Add support for reloading web pages every so many seconds or minutes. The
function is accessible via the context menu (menu you get when you right
click on a webpage) or via tab context menu (right click on the tab).


-- 
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/20120822210349.11165.699.report...@minobo.das-netzwerkteam.de

Re: Minified javascript files

2012-08-22 Thread Pau Garcia i Quiles 
On Wed, Aug 22, 2012 at 8:30 PM, Russ Allbery  wrote:

> I think the debate in this thread is about whether it makes sense to
> require removing the minimized version from the upstream source when we
> don't install that file or otherwise use it in the binary package (because
> the binary package depends on the separately-packaged version of the same
> Javascript library, which already has both the minimized and non-minimized
> version and fully satisfies the DFSG).

That's exactly the point

IMHO, it's just one more useless file in upstream's tarball.

While working today on Wt again, I've noticed if I were to repackage
the upstream tarball to remove jquery.min.js, I would also remove the
Doxygen-generated HTML apidox. After all, I'm also regenerating them,
therefore to me it's just a few thousands of useless files in
upstream's tarball. But what's FTP masters stance on this?

-- 
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/cakcbokskacx5v8eqjcgqoy9sn6sd76kkkge8cmpwq-64nxf...@mail.gmail.com

Re: Minified javascript files

2012-08-22 Thread Russ Allbery 
Pau Garcia i Quiles  writes:

> While working today on Wt again, I've noticed if I were to repackage the
> upstream tarball to remove jquery.min.js, I would also remove the
> Doxygen-generated HTML apidox. After all, I'm also regenerating them,
> therefore to me it's just a few thousands of useless files in upstream's
> tarball. But what's FTP masters stance on this?

I don't think ftp-master particularly cares what additional scrubbing you
do once you have to repackage upstream.  If you don't have to repackage
upstream, there's a strong preference that you don't do so, but once you
go down that path, I don't think anyone is particularly concerned with
what else you change provided that it's generally sensible.  Either one
can verify checksums with the upstream release or one can't.

I drop the Windows code and the products of upstream's autogen.sh in one
of my packages for similar reasons; it saves a few MB of archive space for
code that's never used in Debian, and I have to repackage upstream anyway,
so why not.

-- 
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/87vcga1p4c@windlord.stanford.edu

Re: Minified javascript files

2012-08-22 Thread Vincent Bernat 
 ❦ 23 août 2012 01:01 CEST, Pau Garcia i Quiles  :

>> I think the debate in this thread is about whether it makes sense to
>> require removing the minimized version from the upstream source when we
>> don't install that file or otherwise use it in the binary package (because
>> the binary package depends on the separately-packaged version of the same
>> Javascript library, which already has both the minimized and non-minimized
>> version and fully satisfies the DFSG).
>
> That's exactly the point
>
> IMHO, it's just one more useless file in upstream's tarball.
>
> While working today on Wt again, I've noticed if I were to repackage
> the upstream tarball to remove jquery.min.js, I would also remove the
> Doxygen-generated HTML apidox. After all, I'm also regenerating them,
> therefore to me it's just a few thousands of useless files in
> upstream's tarball. But what's FTP masters stance on this?

You don't need to reove the doxygen documentation since the source is
also present in the tarball.
-- 
Follow each decision as closely as possible with its associated action.
- The Elements of Programming Style (Kernighan & Plauger)


pgpNkdnmA4fFd.pgp
Description: PGP signature