Re: RFC: usb-modeswitch 1.2.0 release embedding jimtcl

[Didier 'OdyX' Raboud]

Le lundi, 27 août 2012 19.21:22, Andrew Shadura a écrit :
> Hello,
> 
> (As a Tcler I have to comment on this.)

> On Tue, 18 Oct 2011 13:36:43 +0200 Didier Raboud  wrote:

(Do you really have to comment on a 10-months old dead thread?)

> > 1) "Forget about jimtcl, rely on existing tcl interpreters"
> > 
> > This is mostly "repacking to avoid the embedded jimtcl copy", "no
> > packaging of it, go on as is done currently; by relying on
> > existing tcl interpreters.
> > 
> > Pros: easy, straightforward,avoids the binary embedding of jimtcl.
> > Cons: does not solve the "desktop install needs tcl interpreter".
> 
> Jimsh is already available, and can be used separately. Also, libjim
> allows linking dynamically.

Yes. Back then, I packaged jimsh and made it create the libjim0debian2 package 
to be able to dynamically link usb-modeswitch's 
/usr/sbin/usb_modeswitch_dispatcher against it. For what is worth, 
libjim0debian2 is 296k (+ changelog and copyright).

> > 5) "Rewrite the usb-modeswitch-dispatcher in C"
> > 
> > This work has already been done by Mathieu Trudel-Lapierre for the
> > Ubuntu ackage.
> > For now, the upstream developer hasn't included this rewrite into
> > 
> > the upstream package (for his own set of reasons). My current
> > strategy is to avoid as much as possible to diverge from upstream,
> > hence why it's not in Debian's usb-modeswitch for now.
> > 
> > Pros: No tcl interpreter needed.
> > Cons: as it's not an upstream effort, it can become out-of-sync
> >   in terms of functionality and bugfixes (and indeed currently is
> >   as of 1.2.0~beta).
> 
> Stupid and useless.

No. That's rather "different approach".

> > What's your opinion ?
> 
> Just link it against libjim, statically or dynamically.

That's been done since Oct. 2011, dynamically. What is your point in reviving 
this thread?

OdyX


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

Re: [proposal] use xz compression for Debian package by default

[Adam Borowski]

On Tue, Aug 28, 2012 at 12:10:18PM +0900, Hideki Yamane wrote:
>  In DebConf12, I talked about xz compression for Debian packages(*).
>  Now I'll talk about next step, suggestion for use xz with with result
>  from some experiment.

> --
> conclusion (rest)
> --
>  I recommend to use xz ***by default*** (with appropriate option) on not only
>  i386/amd64 but on ANY architectures. Increasing extract time can be ignore by
>  decreasing download time and its only part of installation as Mike Hommey 
>  suggested "I/O is still more time consuming than CPU", and nothing worse than
>  high cpu usage.
> 
>  We know some packages are better to use gzip, but it's an exception. Using xz
>  is best choice for rest 99.99% of packages. We can deal with such exception
>  by specifying gzip for that (e.g. openclipart-png).

There's a better compressor here, it's name is "cat" (meow!).  PNG files are
already deflate-compressed, so gzip can't help (higher settings for an
infinitessimal benefit aside).

XZ is smart enough to detect uncompressible files and use "cat" for them,
except for one issue: PNGs are not strictly uncompressible, and xz can often
cut another percent or more.  This means, it will try to compress them which
wastes time from our point of view.  So it not using any compression here
can save CPU for negligible costs.

>  *** what's the best compress option for default? ***
>  *** how to find appropriate compression rate(1, 6 or 9) for xz? ***

I'd say, let's not go there.  The benefits of -9 compression are small and
can break tiny systems (with less than ~100MB of memory) if you're not
careful; -1 produces negligible CPU savings at the cost of often significant
disk space, if the data is incompressible one may want to disable
compression altogether -- but only for packages big enough to bother.

Micromanaging compression levels costs human time, and increases complexity.

> [BCJ filters]
> arch=`dpkg-architecture -qDEB_HOST_ARCH`
> 
> if [ arch = arm | armel | armhf | aarch64 ] // maybe
> set on_arch --arm

If this can be applied blindly to non-code files without a noticeable loss,
that could be good if placed in dpkg-dev.  If not, we're entering the
micromanaging land again.

-- 
Copyright and patents were never about promoting culture and innovations;
from the very start they were legalized bribes to give the king some income
and to let businesses get rid of competition.  For some history, please read
https://en.wikipedia.org/wiki/Statute_of_Monopolies_1623


-- 
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/20120828100525.ga28...@angband.pl

Re: [proposal] use xz compression for Debian package by default

[Bastian Blank]

On Tue, Aug 28, 2012 at 12:10:18PM +0900, Hideki Yamane wrote:
>  We know some packages are better to use gzip, but it's an exception. Using xz
>  is best choice for rest 99.99% of packages. We can deal with such exception
>  by specifying gzip for that (e.g. openclipart-png).

Or even no compression at all. But this needs to be checked.

>  *** what's the best compress option for default? ***
>   low CPU: --check=crc32   -> -10% time

You tested this on a CPU without 64-Bit multiplication unit? Otherwise
it should not be visible.

>   low memory : --lzma2=dict=64KiB (or -0)  -> use 100KiB mem

I think we could go for -2 or -3. You can't run Debian on anything with
less then 32MiB RAM.

>   use arch optimization? : Yes, if we can (*)  -> -10% size

No good idea. The doc clearly stats:

| [...] so it generally isn't good to blindly apply a BCJ filter when
| compressing binary packages for distribution.

>  *** how to find appropriate compression rate(1, 6 or 9) for xz? ***
>   build your package with each option :-)

This is not appropriate. Needing 700MiB to compress is no good idea.

Bastian

-- 
Madness has no purpose.  Or reason.  But it may have a goal.
-- Spock, "The Alternative Factor", stardate 3088.7


-- 
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/20120828100259.gb10...@wavehammer.waldi.eu.org

modemmanager shouldn't recommend usb-modeswitch, but suggest it

[Reinhard Tartler]

Package: modemmanager
Version: 0.5.2.0-1

On Tue, Oct 18, 2011 at 10:58 PM, Michael Biebl  wrote:
> Am 18.10.2011 21:16, schrieb Tollef Fog Heen:
>> ]] Didier Raboud
>
>> |
>> | usb-modeswitch being mostly useful for 3G USB dongles, I don't understand
>> | where you want the s/Recommends/Suggests/.
>>
>> modemmanager shouldn't recommend usb-modeswitch, but suggest it.
>>
>
> The problem then is, that users get failures which are extremely hard to
> debug. The hardware simply won't work for them and we don't have a good way to
> detect such cases and forward a error message to the user session asking them
> to install usb-modeswitch.

If that is the problem, then the current implementation seems more
like a workaround than a fix for this.

> As such type of 3G dongles are quite common, imho the recommends is justified.

There seem to be disagreement on this point. Moreover, users who
choose to not remove modem manager will also fall into this
hard-to-debug situation that you have described above. Let's track
this issue in a proper bugreport (BCC'ed submit@b.d.o).

-- 
regards,
Reinhard


-- 
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/CAJ0cceaeJ78uBu4OWO0vvf=axk86sqzfuujxbc+i+mh_vk4...@mail.gmail.com

Re: About the media types text/x-php and text/x-php-source

[Ian Jackson]

Christoph Anton Mitterer writes ("Re: About the media types text/x-php and 
text/x-php-source"):
> On Mon, 2012-08-27 at 09:02 -0700, Russ Allbery wrote:
> > There are a fair number
> > of email clients out there that, rightly or wrongly, will not display
> > inline attachments of type application/*, but will do so for text/*.
> Not only MUAs, unfortunately.
> 
> > This
> > switch therefore means that attached scripts have to be saved and opened
> > separately rather than viewed directly inline in the mail client, which is
> > occasionally quite awkward.  Or, alternately, one has to attach scripts as
> > text/plain, thus losing the language information that could otherwise be
> > conveyed.  (There are some, although not many, mail clients that, given
> > proper MIME tagging of language information, will do syntax highlighting
> > of attached code.)
> 
> I know that this is a pain in the ares, but actually one should then
> rather try to fix these clients ;-)

But the clients aren't broken.  They simply haven't been taught about
every possible programming language.  That is not a bug.  There will
always be some language whose special mime type is not implemented
everywhere.

The whole point of the text/* classification system is to allow a
sensible fallback in this case.

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/20540.41172.347200.163...@chiark.greenend.org.uk

Bug#686077: ITP: libsnappy1.0.3-java -- Fast Java compressor/decompressor, port of Snappy

[Olivier Sallou]

Package: wnpp
Severity: wishlist
Owner: Olivier Sallou 

* Package name: libsnappy1.0.3-java
  Version : 1.0.3-rc3
  Upstream Author : Xerial.org
* URL : 
https://code.google.com/p/snappy-java/downloads/list?can=4&q=&colspec=Filename+Summary+Uploaded+ReleaseDate+Size+DownloadCount
* License : Apache-2.0
  Programming Lang: Java
  Description : Fast Java compressor/decompressor, port of Snappy

 Java port of Snappy, a fast compresser/decompresser written in C++,
 originally developed by Google. 
 .
 Snappy's main target is very high-speed compression/decompression with
 reasonable compression size. So the compression ratio of snappy-java is
 modest and about the same as LZF (ranging 20%-100% according to the
 dataset). 
 .
 This version of the Java library is not the latest upstream version
 but it has an ABI which is used by picard-tools package and was finally
 packaged exactly for the purpose to support ppicard-tools.


-- 
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/20120828104330.28493.95641.report...@debiansid.genouest.org

Re: About the media types text/x-php and text/x-php-source

[Vincent Lefevre]

On 2012-08-28 04:32:18 +0200, Christoph Anton Mitterer wrote:
> On Mon, 2012-08-27 at 11:03 +0200, Vincent Lefevre wrote:
> > On 2012-08-26 19:55:49 +0200, Christoph Anton Mitterer wrote:
> > > Now obviously there's a small border; I guess IETF's idea is:
> > > "Can it be exectued/interpreted directly or by some interpreter? Then
> > > application/*"
> > 
> > Or compiled & executed, I suppose.
> Well of course,.. but everything compiled is binary,... so for those
> cases it's never questionable that it cannot be "text/"

No, I didn't mean binary, but e.g. C source. In general, C code
is not interpreted, but compiled before being executed.

So, I mean that standalone C source should be application/* based on
the above idea, while a C header file would typically be text/*.

I think this is quite awkward.

> > But what if the intent is to display the source (with specific style),
> > not to run it?
> Uhm... yeah that's the confusing point of the whole:
> MIME-Types never question what's the intent of the content!

I disagree. If a web server serves a CSS file as text/css, you'll get
a different behavior from the one where the same file is served as
text/plain. So, the MIME type is important for a part of the intent.

> You don't have specific mime types for e.g. a PDF for the cases it
> should be displayed or printed.

I'd say that "displayed" and "printed" are similar operations. In both
cases, the content is interpreted (executed) in the same way.

> The same applies for (script) source code, on whether it shall be
> executed or opened in some editor, debugger or e.g. doxygen.
> 
> It's a matter of the user agent, to show a list of possible ways to
> handle a MIME time and a matter of the user to select what he wants.
> Not a matter of the server (who sets the mime type).

But the user agent may have different behaviors depending on the
MIME type, in particular if text/x- is regarded as
a variant of text/plain (contrary to application/*).

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


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120828104604.gd19...@xvii.vinc17.org

Re: Restoring the removed e16 package

[Ian Jackson]

The Wanderer writes ("Restoring the removed e16 package"):
> I'm not positive whether this properly belongs here; if it would be more
> appropriate on another mailing list, just let me know which one.
...
> As e17 does not constitute a suitable replacement for e16 for my
> purposes, I have an interest in seeing e16 continue to be available
> via Debian. What would I need to do to get this package added back
> in?

Find someone (preferably a team) to be the maintainers, prepare a
suitable package, get someone to sponsor it, and reopen all the bugs
which were closed by the removal.

> I would be willing to assume maintainership of the e16 Debian
> package if that is what it would take, although I do not know
> whether I have the skill to be able to do a good job of it.

If you aren't confident of your ability to do this yourself, you
should see if you can find other people to help.

> I am reading the Debian New Maintainers' Guide to educate myself on
> what would be involved with maintaining a package, beyond the
> obvious, and on how to go about getting a package added to
> Debian. However, since this package was previously in the repository
> and has been removed, it seems likely that there would be additional
> considerations beyond those associated with a new package.

Yes.  The new upload should be prepared using the previously-removed
package as a starting point.

> Given the previous removal of this package, the reasons cited for
> that removal, and the (I infer) relative imminence of a new stable
> release, what further requirements and/or deadlines would I need to
> keep in mind as I work on this, and what possible further procedures
> (beyond those in the new-package documentation) would I need to
> follow?

I think it is probably now too late to reintroduce e16 in wheezy.

However your work on e16 probably won't interfere with the wheezy
release so you don't need to do anything special.

The toolchain-related bug seems to be (at least) this one:
 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=554311

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/20540.41659.434921.845...@chiark.greenend.org.uk

Re: [proposal] use xz compression for Debian package by default

[Vincent Lefevre]

On 2012-08-28 12:05:26 +0200, Adam Borowski wrote:
> On Tue, Aug 28, 2012 at 12:10:18PM +0900, Hideki Yamane wrote:
> >  We know some packages are better to use gzip, but it's an
> >  exception. Using xz is best choice for rest 99.99% of packages.
> >  We can deal with such exception by specifying gzip for that (e.g.
> >  openclipart-png).
> 
> There's a better compressor here, it's name is "cat" (meow!).  PNG files are
> already deflate-compressed, so gzip can't help (higher settings for an
> infinitessimal benefit aside).

Before wondering whether PNG files should have an additional
compression level, is there any reason why a better PNG compression
isn't used in the first place? For instance, "optipng -o9" tries
various parameters and keeps the best one.

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


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120828105647.ge19...@xvii.vinc17.org

Re: Minified javascript files

[Ian Jackson]

Stefano Zacchiroli writes ("Re: Minified javascript files"):
> The problem I see with it, is that it adds complexity to the judgement
> of whether something is suitable for a source package or not (on all
> actors involved: maintainer, ftp-masters, QA, bug reporters, etc.). With
> something like that we'll have 3 cases:
> 
> - DFSG-free source[1] -> stay in the tarball, not hidden
> - non DFSG-free "binary" -> must be removed, via repacking
> - "binary" generated from DFSG-free source available elsewhere in the
>   archive -> stay in the tarball, hidden at the dpkg-source level

That's not what I was proposing.  I was proposing that we would treat
your 2nd and 3rd points identically.  They would then be in our
archive in the .orig.tar.gz files.

If this is not ideologically[1] acceptable to other members of the
project in your third case, then I think we should not do it at all
even for the second case.

[1] NB I do not mean to use "ideological" in a pejorative way.  I am
very comfortable with the idea that Debian might make decisions based
on ideology.  The root question being discussed here is IMO
essentially ideological.

If we do decide that we must remove the non-free parts from the
tarballs, repacking upstream's sources, rather than just having them
removed by dpkg-source during unpack, then I certainly welcome the
provision of better tools to help with that.

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/20540.41973.750949.958...@chiark.greenend.org.uk

Re: About the media types text/x-php and text/x-php-source

[Vincent Lefevre]

On 2012-08-28 11:43:32 +0100, Ian Jackson wrote:
> Christoph Anton Mitterer writes ("Re: About the media types text/x-php and 
> text/x-php-source"):
> > On Mon, 2012-08-27 at 09:02 -0700, Russ Allbery wrote:
> > > There are a fair number
> > > of email clients out there that, rightly or wrongly, will not display
> > > inline attachments of type application/*, but will do so for text/*.
> > Not only MUAs, unfortunately.
> > 
> > > This
> > > switch therefore means that attached scripts have to be saved and opened
> > > separately rather than viewed directly inline in the mail client, which is
> > > occasionally quite awkward.  Or, alternately, one has to attach scripts as
> > > text/plain, thus losing the language information that could otherwise be
> > > conveyed.  (There are some, although not many, mail clients that, given
> > > proper MIME tagging of language information, will do syntax highlighting
> > > of attached code.)
> > 
> > I know that this is a pain in the ares, but actually one should then
> > rather try to fix these clients ;-)
> 
> But the clients aren't broken.  They simply haven't been taught about
> every possible programming language.  That is not a bug.  There will
> always be some language whose special mime type is not implemented
> everywhere.

An advantage of text/* is that there isn't a need to teach them.
However the sender must make sure that the provided charset is
correct. Now, the sender could also provide a charset with
application/*, in which case the recipient client should know
that this is necessarily text.

Subversion is also affected by this problem, and unfortunately there
is no way to tell it that some application/* types are text-based.

> The whole point of the text/* classification system is to allow a
> sensible fallback in this case.

Yes.

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


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120828110910.ga9...@xvii.vinc17.org

Re: About the media types text/x-php and text/x-php-source

[Ian Jackson]

Vincent Lefevre writes ("Re: About the media types text/x-php and 
text/x-php-source"):
> On 2012-08-28 11:43:32 +0100, Ian Jackson wrote:
> > But the clients aren't broken.  They simply haven't been taught about
> > every possible programming language.  That is not a bug.  There will
> > always be some language whose special mime type is not implemented
> > everywhere.
> 
> An advantage of text/* is that there isn't a need to teach them.

That's precisely my point.

> However the sender must make sure that the provided charset is
> correct.

Indeed so.

> Now, the sender could also provide a charset with
> application/*, in which case the recipient client should know
> that this is necessarily text.

Is that actually written down in the MIME specs anywhere ?  I wouldn't
have thought that would be a safe assumption at all.

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/20540.44342.115045.484...@chiark.greenend.org.uk

Re: About the media types text/x-php and text/x-php-source

[Ian Jackson]

Vincent Lefevre writes ("Re: About the media types text/x-php and 
text/x-php-source"):
> On 2012-08-28 04:32:18 +0200, Christoph Anton Mitterer wrote:
> > On Mon, 2012-08-27 at 11:03 +0200, Vincent Lefevre wrote:
> > > On 2012-08-26 19:55:49 +0200, Christoph Anton Mitterer wrote:
> > > > Now obviously there's a small border; I guess IETF's idea is:
> > > > "Can it be exectued/interpreted directly or by some interpreter? Then
> > > > application/*"

This is the wrong way to think of it.  The right way is "is it
intended by the sender to be executed by the recipient _as part of
display of the message_" ?

For programming language source code this will rarely be the case.

If the source file is intended to be executed as part of displaying
the message then application/* is right because showing the source as
text will not do what the sender intended.  If not then text/* is
right because what's wanted is to show the source code to the
recipient and a fallback to plain text display (rather than say a
fancy syntax highligher or IDE) is correct.

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/20540.44525.663191.178...@chiark.greenend.org.uk

Re: About the media types text/x-php and text/x-php-source

[Ian Jackson]

Ian Jackson writes ("Re: About the media types text/x-php and 
text/x-php-source"):
> This is the wrong way to think of it.  The right way is "is it
> intended by the sender to be executed by the recipient _as part of
> display of the message_" ?

Oh and I should draw the obvious conclusion about PHP.  If you attach
a ".php" file to an email, you do not intend for the recipient to
execute it.  PHP files should not be executed routinely; rather, they
should be executed only when that is clearly intended.  So *.php
should be text/x-php.

The same applies to Perl, Python, etc.

If it is conventional to drop files called *.php into webserver trees,
without marking them executable or configuring the webserver for them,
and expect the webserver to execute them, then that is a matter for
the webserver and not something that should be done via the mime type
system.

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/20540.44918.606992.66...@chiark.greenend.org.uk

Re: Bug#686075: modemmanager shouldn't recommend usb-modeswitch, but suggest it

[Reinhard Tartler]

On Tue, Aug 28, 2012 at 1:16 PM, Didier 'OdyX' Raboud  wrote:
> (Dropping -devel)
>
> Hi Reinhard,
>
> Le mardi, 28 août 2012 12.18:31, Reinhard Tartler a écrit :
>> Package: modemmanager
>> Version: 0.5.2.0-1
>>
>> On Tue, Oct 18, 2011 at 10:58 PM, Michael Biebl  wrote:
>> > Am 18.10.2011 21:16, schrieb Tollef Fog Heen:
>> >>
>> >> modemmanager shouldn't recommend usb-modeswitch, but suggest it.
>> >
>> > The problem then is, that users get failures which are extremely hard to
>> > debug. The hardware simply won't work for them and we don't have a good
>> > way to detect such cases and forward a error message to the user session
>> > asking them to install usb-modeswitch.
>>
>> If that is the problem, then the current implementation seems more
>> like a workaround than a fix for this.
>
> In that case, what would be the fix?

I'd suggest to signal the situation properly to the user. This would
make the situation less hard to identify.

Ideally, the user is presented some dialog box that instructs him to
install the missing usb-modeswitch pacakge if necessary when he plugs
in his 3g dongle.

>>  Moreover, users who
>> choose to not remove modem manager will also fall into this
>> hard-to-debug situation that you have described above.
>
> I don't understand this assertion. The problem (the hard-to-debug situations)
> arises when users have a) a 3G dongle, b) network-manager, c) modemmanager but
> d) not usb-modeswitch. In that case, most 3G dongle never ever appear to the
> user as "modems", only as unwriteable USB Mass Storage. If, as user, you never
> heard of the modeswitching problem, then you have no chance to realize you
> need to go manually hunt the suggests of the recommends of network-manager.
>
> This problem is _solved_ by the fact that modemmanager Recommends usb-
> modeswitch and thereby avoids the above situation by having usb-modeswitch
> transform these useless USB Mass Storage devices into proper modems.

So there is absolutely no chance to distinguish such a 3g dongle from
a regular mass-storage stick  without the usb-modeswitch package?

> IMHO, this bug should be either closed or marked +wontfix .

Since this seems a somewhat recurring issue on debian-devel, +wontfix
seems more appropriate to me, but of course YMMV.

-- 
regards,
Reinhard


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

Re: Bug#686075: modemmanager shouldn't recommend usb-modeswitch, but suggest it

[Michael Biebl]

On 28.08.2012 14:07, Reinhard Tartler wrote:
> On Tue, Aug 28, 2012 at 1:16 PM, Didier 'OdyX' Raboud  wrote:
>> (Dropping -devel)
>>
>> Hi Reinhard,
>>
>> Le mardi, 28 août 2012 12.18:31, Reinhard Tartler a écrit :
>>> Package: modemmanager
>>> Version: 0.5.2.0-1
>>>
>>> On Tue, Oct 18, 2011 at 10:58 PM, Michael Biebl  wrote:
 Am 18.10.2011 21:16, schrieb Tollef Fog Heen:
>
> modemmanager shouldn't recommend usb-modeswitch, but suggest it.

 The problem then is, that users get failures which are extremely hard to
 debug. The hardware simply won't work for them and we don't have a good
 way to detect such cases and forward a error message to the user session
 asking them to install usb-modeswitch.
>>>
>>> If that is the problem, then the current implementation seems more
>>> like a workaround than a fix for this.
>>
>> In that case, what would be the fix?
> 
> I'd suggest to signal the situation properly to the user. This would
> make the situation less hard to identify.
> 
> Ideally, the user is presented some dialog box that instructs him to
> install the missing usb-modeswitch pacakge if necessary when he plugs
> in his 3g dongle.
> 

We don't have the infrastructure though, to do such hardware based
installation requests, i.e. a system service which constantly monitors
newly plugged in devices, has a database of devices mapping to packages,
and a service running in the user session which can be signaled via the
system service (e.g. via D-Bus) when such a hardware has been plugged
in, and presents that to the user.

This would certainly be a neat idea and once we have that and is widely
used, we can adjust the package relation ship between modemmanager and
usb-modeswitch.


Michael

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Re: Bug#684726: ITP: check_v46 -- Icinga / Nagios plugin for dual stacked (IPv4 / IPv6) hosts

[Bernd Zeimetz]

On 08/13/2012 06:13 PM, Christoph Anton Mitterer wrote:
> On Mon, 2012-08-13 at 15:41 +0200, Martin Wuertele wrote:
>> Would it make sense to included it in nagios-plugins-contrib?
> Actually I'd prefer to have nagios-contrib split up... I mean I think
> that's to some extent a general Debian problem, that there are such
> package collections, with a high number of deps (via
> recommends/suggests), and the user has to look himself which ones he
> really needs.
> That's kinda stupid IMHO,... as it makes the dependency system useless.

Then just install everything in recommends (which is actually the
default unless you disabled the installation of recommends, which is
your problem then) and be happy. You'll end up with some megabytes of
libgraries, nothing that will do any harm unless you are out of diskspace.


> It's maybe a different thing though, for very closely integrated things
> like devrscripts,.. but even there it's quite annoying to find out which
> needs what (and they have quite some good package description).

Again, recommends are installed by default. If one of the plugins in the
package does not work for you out of the box (and you have the
recommended packages installed), file a bug.


-- 
 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/503cbd4a.8080...@bzed.de

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

[Bernd Zeimetz]

On 08/10/2012 10:55 AM, Marco d'Itri wrote:
> On Aug 10, Philip Hands  wrote:
> 
>> Now that they've done the bulk of the effort, do you really expect them
>> to simply discard their work because you tell them to?
> I really do not care about what the openrc developers will do, my 
> interest is in what Debian developers will do.

No, Your interest is only what you like. And your second interest is
trying to force other people to share your opinion.

>> So, please tell us about the corrosive harm that you think is going to
>> result from this being allowed into the archive (in detail, with
>> references), or let them get on with it.
> There are two main issues with trying to support multiple init systems.
> The first one is the time needed to do it.

If the project decides that this is the way to go, you'll have to live
with it. So far I can't see how using openrc wastes time at all so far.
Wasting my time are all the systemd fanboys who want their
please-make-that-compatible-with-systemd patches applied.

> The second and more important 
> one is being limited by the features of the less capable implementation, 
> which would be a disgrace.

So far I can see nothing that would make me feel limited by openrc.


-- 
 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/503cba72.8040...@bzed.de

Re: About the media types text/x-php and text/x-php-source

[Christoph Anton Mitterer]

Ian,...

Again, AFAIU, IETF nor the RFCs do consider the MIME types as way to
determine what the sender/creator intends the recipient to do with it.

So any assumptions you made about files attached to emails, etc. do IMHO
simply not fit.
And actually that's the way we already have; the clients give the user a
choice of e.g. programs what to do.

Just look at IETF's handling of ecmascript and javascript types, where
text/* was deprecated.
And PHP is of the same kind here.


Cheers,
Chris.


smime.p7s
Description: S/MIME cryptographic signature

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

[Bernd Zeimetz]

On 08/10/2012 09:25 AM, Martin Wuertele wrote:
> * Josselin Mouette  [2012-08-09 23:15]:
> 
>> And no, choice between multiple broken implementation is NOT added
>> value. Linux is not about choice.
> 
> Luckily that is not everyones opinion.

Strong ack. I'm using open source software because I want to to be able
to choose.


-- 
 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/503cbabd.4080...@bzed.de

Re: Bug#684726: ITP: check_v46 -- Icinga / Nagios plugin for dual stacked (IPv4 / IPv6) hosts

[Christoph Anton Mitterer]

Hi Bernd.

On Tue, 2012-08-28 at 14:44 +0200, Bernd Zeimetz wrote:
> > Actually I'd prefer to have nagios-contrib split up... I mean I think
> > that's to some extent a general Debian problem, that there are such
> > package collections, with a high number of deps (via
> > recommends/suggests), and the user has to look himself which ones he
> > really needs.
> > That's kinda stupid IMHO,... as it makes the dependency system useless.
> Then just install everything in recommends (which is actually the
> default unless you disabled the installation of recommends, which is
> your problem then) and be happy.
Well but many people disable this, because otherwise you get "tons" of
stuff you don't need nor want.
And Recommends here is merely a "workaround", isn't it?

The policy's definition of recommends is rather vague, but I think it's
often use when a package is required to use "optional" functionality of
the recommending package.

But when you look at compilation packages like nagios-contrib, the
single components often _depend_ on the recommended packages.

That's what I meant :)


> You'll end up with some megabytes of
> libgraries, nothing that will do any harm unless you are out of diskspace.
Well,... and sometimes even daemons, new users/groups, etc. pp.

:)

Cheers,
Chris.


smime.p7s
Description: S/MIME cryptographic signature

Re: About the media types text/x-php and text/x-php-source

[Vincent Lefevre]

On 2012-08-28 12:36:22 +0100, Ian Jackson wrote:
> Vincent Lefevre writes ("Re: About the media types text/x-php and 
> text/x-php-source"):
> > Now, the sender could also provide a charset with
> > application/*, in which case the recipient client should know
> > that this is necessarily text.
> 
> Is that actually written down in the MIME specs anywhere ?  I wouldn't
> have thought that would be a safe assumption at all.

Providing a charset parameter is explicitly allowed. In RFC 2046:

   Other media types than subtypes of "text" might choose to employ the
   charset parameter as defined here, but with the CRLF/line break
   restriction removed.  Therefore, all character sets that conform to
   the general definition of "character set" in RFC 2045 can be
   registered for MIME use.

Then if there is a charset parameter, with a value that refers to
some known text character set, I think that one can assume that
the contents are encoded with this charset, thus can be displayed
as text.

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


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120828130426.gf19...@xvii.vinc17.org

Re: Bug#686075: modemmanager shouldn't recommend usb-modeswitch, but suggest it

[Didier 'OdyX' Raboud]

.oO(I thought I had explicitely dropped -devel, meh).

Le mardi, 28 août 2012 14.07:40, Reinhard Tartler a écrit :
> I'd suggest to signal the situation properly to the user. This would
> make the situation less hard to identify.
> 
> Ideally, the user is presented some dialog box that instructs him to
> install the missing usb-modeswitch pacakge if necessary when he plugs
> in his 3g dongle.
>
> (…)
> 
> So there is absolutely no chance to distinguish such a 3g dongle from
> a regular mass-storage stick  without the usb-modeswitch package?

AFAIK no. And if that would be the case, there would be no need for usb-
modeswitch. If you're looking for a database of culprit hardware, then that 
_is_ usb-modeswitch-data. Dropping that pair from "all but unusual 
installations" leaves users with these culprit dongles in the blind without a 
way to know (or guess fwiw) that they would need "usb-modeswitch".

Cheers,

OdyX


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

Re: Bug#686075: modemmanager shouldn't recommend usb-modeswitch, but suggest it

[Marco d'Itri]

On Aug 28, Michael Biebl  wrote:

> We don't have the infrastructure though, to do such hardware based
> installation requests, i.e. a system service which constantly monitors
> newly plugged in devices, has a database of devices mapping to packages,
> and a service running in the user session which can be signaled via the
> system service (e.g. via D-Bus) when such a hardware has been plugged
> in, and presents that to the user.
I think Ubuntu has something like this, udev would do most of the work.

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Re: About the media types text/x-php and text/x-php-source

[Vincent Lefevre]

On 2012-08-28 14:49:53 +0200, Christoph Anton Mitterer wrote:
> Ian,...
> 
> Again, AFAIU, IETF nor the RFCs do consider the MIME types as way to
> determine what the sender/creator intends the recipient to do with it.

Perhaps it would be more clear like that: one may want to consider
a script as a program/application that can be executed, in which
case application/* should be used; but one may also want to regard
it as text, in which case text/plain can be used. The IETF doesn't
forbid such a choice.

text/x-* could be regarded as non-standard variants of text/plain,
while still providing language information.

> Just look at IETF's handling of ecmascript and javascript types, where
> text/* was deprecated.

They are deprecated *for execution*. If the user wants to distribute
the source, meant as visible as text, then text/plain and text/x-*
are fine.

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


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120828132004.gg19...@xvii.vinc17.org

Re: About the media types text/x-php and text/x-php-source

[Christoph Anton Mitterer]

On Tue, 2012-08-28 at 15:20 +0200, Vincent Lefevre wrote:
> Perhaps it would be more clear like that: one may want to consider
> a script as a program/application that can be executed, in which
> case application/* should be used; but one may also want to regard
> it as text, in which case text/plain can be used. The IETF doesn't
> forbid such a choice.
Well but it doesn't endorse it either; at least I've never read anything
like this.
And actually, as said before, I think it "breaks" what MIME-types are
defined as, which is a media type, but in _no way_ a hint which choice
is to be selected, when multiple are available for it's interpretation.

Of course we can technically do this, but this is then something which
we purely make up in our minds and which is no where (again, none of the
RFCs, etc. I'd know) defined like this.



> > Just look at IETF's handling of ecmascript and javascript types, where
> > text/* was deprecated.
> They are deprecated *for execution*. If the user wants to distribute
> the source, meant as visible as text, then text/plain and text/x-*
> are fine.
That's not true:
RFC4329, section 7.1 and 8.1 mark text/javascript and text/ecmascript
unconditionally as obsolete.



Cheers,
Chris.


smime.p7s
Description: S/MIME cryptographic signature

Re: About the media types text/x-php and text/x-php-source

[Vincent Lefevre]

On 2012-08-28 15:53:51 +0200, Christoph Anton Mitterer wrote:
> On Tue, 2012-08-28 at 15:20 +0200, Vincent Lefevre wrote:
> > Perhaps it would be more clear like that: one may want to consider
> > a script as a program/application that can be executed, in which
> > case application/* should be used; but one may also want to regard
> > it as text, in which case text/plain can be used. The IETF doesn't
> > forbid such a choice.
> Well but it doesn't endorse it either; at least I've never read anything
> like this.
> And actually, as said before, I think it "breaks" what MIME-types are
> defined as, which is a media type, but in _no way_ a hint which choice
> is to be selected, when multiple are available for it's interpretation.

It doesn't break anything. If the goal is to read the file as text,
then text/plain is fine.

> > > Just look at IETF's handling of ecmascript and javascript types, where
> > > text/* was deprecated.
> > They are deprecated *for execution*. If the user wants to distribute
> > the source, meant as visible as text, then text/plain and text/x-*
> > are fine.
> That's not true:
> RFC4329, section 7.1 and 8.1 mark text/javascript and text/ecmascript
> unconditionally as obsolete.

You misread what I've said. text/javascript and text/ecmascript
(which were used for execution -- this is what this RFC is about)
are obsolete, but not text/plain.

Sending a JavaScript file by e-mail with the text/plain type is fine.
text/x-javascript could be used to, in order to provide information
about the language, even though it is not standard (hence the "x-").

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


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120828140524.gh19...@xvii.vinc17.org

Re: Bug#686075: modemmanager shouldn't recommend usb-modeswitch, but suggest it

[Michael Biebl]

On 28.08.2012 14:49, Marco d'Itri wrote:
> On Aug 28, Michael Biebl  wrote:
> 
>> We don't have the infrastructure though, to do such hardware based
>> installation requests, i.e. a system service which constantly monitors
>> newly plugged in devices, has a database of devices mapping to packages,
>> and a service running in the user session which can be signaled via the
>> system service (e.g. via D-Bus) when such a hardware has been plugged
>> in, and presents that to the user.
> I think Ubuntu has something like this, udev would do most of the work.

Interesting. Does anyone know more about that?


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Re: Restoring the removed e16 package

[The Wanderer]

On 08/28/2012 06:51 AM, Ian Jackson wrote:


The Wanderer writes ("Restoring the removed e16 package"):


I'm not positive whether this properly belongs here; if it would be more
appropriate on another mailing list, just let me know which one.


On this point, I've already been advised (by Bart Martens, in off-list mail)
that debian-mentors would probably be a more appropriate venue. The only reason
I haven't posted over there yet is that I'm still digging through the bugs and
trying to work out an appropriate starting point (especially given the nature of
some of those bugs), so that I know exactly what I want to post.


As e17 does not constitute a suitable replacement for e16 for my purposes,
I have an interest in seeing e16 continue to be available via Debian. What
would I need to do to get this package added back in?


Find someone (preferably a team) to be the maintainers, prepare a suitable
package, get someone to sponsor it, and reopen all the bugs which were closed
by the removal.


I'm a little surprised by this last point. Since I wouldn't have thought it
would seem appropriate to add (or re-add) a known-buggy package to the
repository, I would have thought getting the package restored would involve
finding fixes for all of those bugs first, and there wouldn't seem to be much
point in reopening bugs just to close them again - either because they're fixed
in the re-added package, or because the attempt to restore the package didn't
work out.

The only reason I can think of would be documentation - to record that the bug
has in fact been officially fixed, rather than simply lost in the shuffle. Is
that the only reason for that step, or is there more which I'm missing?


I would be willing to assume maintainership of the e16 Debian package if
that is what it would take, although I do not know whether I have the skill
to be able to do a good job of it.


If you aren't confident of your ability to do this yourself, you should see
if you can find other people to help.


While that's obviously good advice, it's also potentially easier said than done.

The only other people I currently know of who care about e16 and have any
technical skill are the former package maintainer, several members of my current
household (most of whom would be at least as inclined to just compile it
themselves), and the current upstream maintainer. I also haven't yet found any
e16-related communities or discussion forums in which to look for others (except
for the general Enlightenment mailing lists, which are mostly swamped with e17
these days).

While the upstream maintainer can probably help with the program itself, it
wouldn't be terribly nice to just try to dump everything on (her?), and the
packaging work is another question.

Overall, while I certainly wouldn't mind having help, I don't think I can in
good conscience take up the maintainer role without being able to handle it all
myself if I need to.


I am reading the Debian New Maintainers' Guide to educate myself on what
would be involved with maintaining a package, beyond the obvious, and on
how to go about getting a package added to Debian. However, since this
package was previously in the repository and has been removed, it seems
likely that there would be additional considerations beyond those
associated with a new package.


Yes.  The new upload should be prepared using the previously-removed package
as a starting point.


That's been my plan since the beginning. There is at least one bug that makes
doing this in the most straightforward way (reintroducing the removed package
version verbatim, then making changes off of that) questionably appropriate, but
that's what I've been working on in the interim since posting.


Given the previous removal of this package, the reasons cited for that
removal, and the (I infer) relative imminence of a new stable release, what
further requirements and/or deadlines would I need to keep in mind as I
work on this, and what possible further procedures (beyond those in the
new-package documentation) would I need to follow?


I think it is probably now too late to reintroduce e16 in wheezy.


Unfortunate, but not hugely surprising. I presume a later backport would still
be reasonable?


However your work on e16 probably won't interfere with the wheezy release so
you don't need to do anything special.

The toolchain-related bug seems to be (at least) this one:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=554311


Ah. No wonder I didn't find that one; I was looking at bugs against e16 and
e16-data, not the corresponding source package. (I hadn't even previously
realized that you *could* search for, or even file, bugs against a source
package separately.)

The description of the problem as reported in that bug is a little confusing
(the ld.bfd man page seems to match what the bug says is default for
binutils-gold, and the ld.gold man page seems to match the reverse), but the
symptoms do manifest as described.

Initial testing ind

Re: About the media types text/x-php and text/x-php-source

[Christoph Anton Mitterer]

On Tue, 2012-08-28 at 16:05 +0200, Vincent Lefevre wrote:
> It doesn't break anything.
Well one should usually not add any "personal" interpretations to
standards,... because eventually this will cause troubles.


> If the goal is to read the file as text,
> then text/plain is fine.
Ah... I guess I over-read that :D I thought you were talking about e.g.
"text/x-php"...
text/plain is of course fine, as well as (for example)
application/octet-stream.


> You misread what I've said. text/javascript and text/ecmascript
> (which were used for execution -- this is what this RFC is about)
> are obsolete, but not text/plain.
Yep you're right,... I over-read that :D... but this thread goes about
text/x-php, which I still think would be wrong,... not about marking
them as text/plain.

> text/x-javascript could be used to, in order to provide information
> about the language, even though it is not standard (hence the "x-").
Yeah,.. could... but... I think adding a x- type for widespread use
should always be the last solution, sooner or later these may cause
troubles.
And if e.g. an email client is smart enough to know that
text/x-javascript is not to be executed but that it should use
JavaScript highlighting, then it can easily be smart enough, too, to
know that it shouldn't execute application/javascript per default, but
rather display it.


Cheers,
Chris.


smime.p7s
Description: S/MIME cryptographic signature

Re: [proposal] use xz compression for Debian package by default

[Riku Voipio]

On Tue, Aug 28, 2012 at 12:10:18PM +0900, Hideki Yamane wrote:
> --
> conclusion (rest)
> --
>  I recommend to use xz ***by default*** (with appropriate option) on not only
>  i386/amd64 but on ANY architectures. Increasing extract time can be ignore by
>  decreasing download time and its only part of installation as Mike Hommey 
>  suggested "I/O is still more time consuming than CPU", and nothing worse than
>  high cpu usage.

Thanks for your detailed tests.

Wearing armel buildd maintainer hat, I agreei with the conclusion. 1.5x slower
decompression is small enough hit and as mentioned decompression is only a part 
of
package install time.

It is worth noticing that using xz by default will slow down package builds 
(especially
ones with huge -dbg packages, but we are already working on getting faster 
armel/armhf
build machines.

Riku


-- 
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/20120828135531.ga6...@afflict.kos.to

Re: About the media types text/x-php and text/x-php-source

[Ian Jackson]

Vincent Lefevre writes ("Re: About the media types text/x-php and 
text/x-php-source"):
> Then if there is a charset parameter, with a value that refers to
> some known text character set, I think that one can assume that
> the contents are encoded with this charset, thus can be displayed
> as text.

I don't think that follows at all.  It might just mean that the text
in (say) the zipfile filenames is in whatever charset is specified.

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/20540.55233.451440.425...@chiark.greenend.org.uk

Re: About the media types text/x-php and text/x-php-source

[Ian Jackson]

Christoph Anton Mitterer writes ("Re: About the media types text/x-php and 
text/x-php-source"):
> On Tue, 2012-08-28 at 16:05 +0200, Vincent Lefevre wrote:
> > You misread what I've said. text/javascript and text/ecmascript
> > (which were used for execution -- this is what this RFC is about)
> > are obsolete, but not text/plain.

I think this is probably a mistake by the IETF.

> Yep you're right,... I over-read that :D... but this thread goes about
> text/x-php, which I still think would be wrong,... not about marking
> them as text/plain.

Do you think then that the source code language (eg for syntax
highlighting or whatever) should never be represented in a mime type ?
Or perhaps it should be an attribute ?

> > text/x-javascript could be used to, in order to provide information
> > about the language, even though it is not standard (hence the "x-").
>
> Yeah,.. could... but... I think adding a x- type for widespread use
> should always be the last solution, sooner or later these may cause
> troubles.

I don't agree with this.

> And if e.g. an email client is smart enough to know that
> text/x-javascript is not to be executed but that it should use
> JavaScript highlighting, then it can easily be smart enough, too, to
> know that it shouldn't execute application/javascript per default, but
> rather display it.

In the latter case we need to teach _all_ user agents to display
application/javascript rather than do something else with it.  In the
former case we only need to teach anything to those user agents for
which text/we think a prettier display than that available for
text/plain is desirable.

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/20540.55440.915217.544...@chiark.greenend.org.uk

Re: Restoring the removed e16 package

[Ian Jackson]

The Wanderer writes ("Re: Restoring the removed e16 package"):
> On this point, I've already been advised (by Bart Martens, in
> off-list mail) that debian-mentors would probably be a more
> appropriate venue.

Fair enough.  I'll try to keep my response here to one point which I
think is probably of general interest.

> > Find someone (preferably a team) to be the maintainers, prepare a
> > suitable package, get someone to sponsor it, and reopen all the
> > bugs which were closed by the removal.
> 
> I'm a little surprised by this last point. Since I wouldn't have thought it
> would seem appropriate to add (or re-add) a known-buggy package to the
> repository,

"A suitable package" means one that is fit for release, obviously.
Assembling a team who were happy to be the maintainers would naturally
mean a team who are happy that they can fix the RC bugs.

I spoke loosely about the bugs.  I think the right procedure would be
to reopen /all/ the bugs before uploading the new package, and then
allow the changelog entry of the new package to close the ones that
had actually been fixed in the new version.

(An RC-buggy package will not end up in a Debian release provided it's
properly tagged in the BTS.  So I think in principle it can be
appropriate to upload an RC-buggy package to the archive if you have a
plan for fixing the bugs and there is some reason why it is better to
do it that way - eg, perhaps there are dependencies and working on the
whole lot in unstable is easier.)

> The only reason I can think of would be documentation - to record
> that the bug has in fact been officially fixed, rather than simply
> lost in the shuffle. Is that the only reason for that step, or is
> there more which I'm missing?

It is unlikely that the new package would fix all of the bugs in the
package.  It is mostly straightforward to automatically reopen all the
bugs which were fixed by the removal.  Closing the fixed bugs in the
changelog is easy.  The result is that the set of bugs remaining open
in the BTS is correct, and it will be easier to avoid mistakes.

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/20540.55960.483296.271...@chiark.greenend.org.uk

Re: About the media types text/x-php and text/x-php-source

[Christoph Anton Mitterer]

On Tue, 2012-08-28 at 15:41 +0100, Ian Jackson wrote:
> > > You misread what I've said. text/javascript and text/ecmascript
> > > (which were used for execution -- this is what this RFC is about)
> > > are obsolete, but not text/plain.
> I think this is probably a mistake by the IETF.
Well, I doubt, but anyway... I guess than one would need to discuss with
them to correct it.


> Do you think then that the source code language (eg for syntax
> highlighting or whatever) should never be represented in a mime type ?
I think it already is when you use e.g. application/javascript.
And I think, that MIME types are intended to hint the client of what
kind content is, but not what to do with it.
The clients can then decide what to do, depending on fit's best for
them, or ask the user, or do the action the user has previously
configured.

In the specific example of interpretable scripts, it's of course
reasonable to not set the default action to execute it (for security
reason).
But that's not something the server should tell (by the MIME-type),...
it cannot know what the client/user really wants... and it would be
insecure to trust any remote server to make the right choice.


> > Yeah,.. could... but... I think adding a x- type for widespread use
> > should always be the last solution, sooner or later these may cause
> > troubles.
> I don't agree with this.
Well... x- types were never intended to be used in production.

- They always bear the risk, that they're ambiguous, Microsoft defined
it to be xyz, Adobe defined it to be zxy.

- Once you've defined (and used) them widely, you cannot easily get rid
of them. The application/x-httpd-* case is an example, as well as
several types for which previously an x-type existed but now a real
definition was made.
Both continue to be used and for both code has to be maintained.

- People often "defined" x-types without really knowing what they do.
There are types for bzip2 or gzip floating around (luckily not in
Debian's mime-support) which are however not types, but encodings.

- And x-type gives you no guarantee at all, that anyone else agrees with
it or even supports it. Of course the same is true with official types,
but there one at least has kind of a "strong" argument, that 3rd parties
should support them, which you don't have IMHO with x-types.


> In the latter case we need to teach _all_ user agents to display
> application/javascript rather than do something else with it.
Yeah,... but what else? I mean user agents that unconditionally try to
execute/interpret application/* content are seriously flawed...


> In the
> former case we only need to teach anything to those user agents for
> which text/we think a prettier display than that available for
> text/plain is desirable.
Well at least for the cases I know (but these are surely not all),... it
works already fine as it is... either they understand that e.g.
application/javascript is to be displayed as text in editor (e.g. with
syntax highlighting)... or in case of text/plain,.. they try anyway to
automagically determine the correct highlighting.

Even if we'd need to fix any client... we're in the open source world,
arent't we? In most cases it's just a one liner to tell an user agent
that it should connect type application/foo with e.g. editor bar.

Of course you can argue that we can't to this for proprietary crap,...
but why should we mess up our systems to make their crap work out of the
box?
I just suffered (few minutes ago) again from an issue in Outlook, that
it cannot display S/MIME signed (not encrypted) mails if it doesn't know
the key... it does not just warn, it really cannot display it.
Now should I change my working and correct setup just to please any big
company like Dell which uses Outlook?

And if a server admin really needs to do this,... he can always manually
add such types,... but IMHO there's no need to "poison" all users with
them ;)




Anyway... I guess the whole discussion went highly off topic, didn't it?
The question is what should be done for text/x-php and text/x-php-source
and from my side I've already said mostly everything what I'd do and
that I think using mod_negotiation for "tidy" URLs is an abuse an
shouldn't be supported :)



Cheers
Chris.


smime.p7s
Description: S/MIME cryptographic signature

Re: About the media types text/x-php and text/x-php-source

[Ian Jackson]

Christoph Anton Mitterer writes ("Re: About the media types text/x-php and 
text/x-php-source"):
> I think it already is when you use e.g. application/javascript.
> And I think, that MIME types are intended to hint the client of what
> kind content is, but not what to do with it.

I think that's a meaningless distinction.  The purpose of the MIME
type is to ensure that the client behaves correctly.

> > In the
> > former case we only need to teach anything to those user agents for
> > which text/we think a prettier display than that available for
> > text/plain is desirable.
>
> Well at least for the cases I know (but these are surely not all),... it
> works already fine as it is... either they understand that e.g.
> application/javascript is to be displayed as text in editor (e.g. with
> syntax highlighting)... or in case of text/plain,.. they try anyway to
> automagically determine the correct highlighting.

I have frequently encountered problems viewing various kinds of code
when the web server quoted an application/x-blah-source-code content
type.  If the web server quotes text/x-blah-source-code then at least
there's a hope of success.

> Even if we'd need to fix any client... we're in the open source world,
> arent't we? In most cases it's just a one liner to tell an user agent
> that it should connect type application/foo with e.g. editor bar.

You seem to be living in a world where all the software you are using
is all from exactly the same time and there are never any transitional
arrangements are needed, and where there is unlimited effort for
updating client software for obscure new content types.

That's not the real world.

> Anyway... I guess the whole discussion went highly off topic, didn't it?
> The question is what should be done for text/x-php and text/x-php-source
> and from my side I've already said mostly everything what I'd do and
> that I think using mod_negotiation for "tidy" URLs is an abuse an
> shouldn't be supported :)

*.php files should be recognised as text/x-php or text/x-php-source by
our mime types file.

If Apache (or some other webserver) wants to automatically execute
*.php files (whether the url referring to foo.php is is
http://example.com/foo.php or http://example.com/foo) then that should
be achieved by webserver configuration, and should not involve any
changes to the filename-based mime type recognition system used for
the rest of the system (eg mutt).

I don't have an opinion about how the webserver config should be done,
except that it should be done in a way that won't result in files
being executed contrary to the intention of the administrator.

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/20540.57729.611383.628...@chiark.greenend.org.uk

Proposal: Making Debian compiler agnostic

[Sylvestre Ledru]

Hello,

This summer, during the Google Summer of Code (GSoC), we have been
working to provide a way to rebuild the archive with a non-gcc compiler
(in our case: clang).

Our project's intent is not to change the default compiler, just use a
secondary compiler to generate more errors or warnings for package
maintainers to be aware of. In most cases, keeping both compilers happy
would result in higher quality code, something I think we can all get
behind.

During our work, we have found a few interesting issues, and would like
to push for some package policy changes for Jessie.

Currently, it is the case that some packages are expecting gcc and g++
to be the default and (almost) only C and C++ compilers. While it has
been the case for the early days of the project, this assumption causes
more and more issues for folks who want to use something _other_ then
gcc or g++.

A lot of packages featuring "NIH" build toolchains do not respect CC, in
a lot of cases. This will be the source of most of the problems, as most
autotool or cmake setups should respect CC.

As a next step, we would like to propose that all packages respect $CC
and $CXX, when set.

In cases where this is not technically possible, /usr/bin/cc or
/usr/bin/c++ should be used in place of /usr/bin/gcc or /usr/bin/g++,
although this is discouraged as well, and should not crop up often (if
at all), as doing this will make life very hard for cross-builders

The idea here is not so much for our project in of it's self, it is to
make sure we respect user-local configuration, or system-wide
configuration, regardless of what compiler that is.

We would like to propose the same approach for Fortran and Objective-C,
but it seems that it is not as clear as the C/C++ convention. If someone
could provide sane env-vars for these two, it would be very helpful.

We should also make the following assumption -- the CC / CXX compiler
will accept gcc compatible arguments, with only very minor changes that
are gcc compatible as well (such as using -O3 rather then the
meaningless -O6, etc). The clang compiler, for example, considers
incompatible arguments with gcc a bug.

Therefore, we would like to propose an update of Debian policy, to take
effect after the Wheezy release.

"4.9 Main building script: debian/rules"
stating:
-
Hardcoded usage of CC or CXX (for example, CC=gcc) should be avoid and
documented if necessary.
Debian build tools must respect the CC and CXX variables if provided. If
not, they shall default to /usr/bin/cc and /usr/bin/c++
-

If a rough consensus is reached it is our intent to make this into a
release goal.

Thanks,
Sylvestre Ledru and Paul Tagliamonte



--
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/503ce158.5090...@debian.org

Re: Proposal: Making Debian compiler agnostic

[Mike Dupont]

Hi there,
I love the gcc and fully support it. Not only should we support different
gcc options but of course other compilers like the llvm.
There are also things like profile feedback that could be interesting to
collect on a project wide basis.
mike

On Tue, Aug 28, 2012 at 5:18 PM, Sylvestre Ledru wrote:

> Hello,
>
> This summer, during the Google Summer of Code (GSoC), we have been
> working to provide a way to rebuild the archive with a non-gcc compiler
> (in our case: clang).
>
> Our project's intent is not to change the default compiler, just use a
> secondary compiler to generate more errors or warnings for package
> maintainers to be aware of. In most cases, keeping both compilers happy
> would result in higher quality code, something I think we can all get
> behind.
>
> During our work, we have found a few interesting issues, and would like
> to push for some package policy changes for Jessie.
>
> Currently, it is the case that some packages are expecting gcc and g++
> to be the default and (almost) only C and C++ compilers. While it has
> been the case for the early days of the project, this assumption causes
> more and more issues for folks who want to use something _other_ then
> gcc or g++.
>
> A lot of packages featuring "NIH" build toolchains do not respect CC, in
> a lot of cases. This will be the source of most of the problems, as most
> autotool or cmake setups should respect CC.
>
> As a next step, we would like to propose that all packages respect $CC
> and $CXX, when set.
>
> In cases where this is not technically possible, /usr/bin/cc or
> /usr/bin/c++ should be used in place of /usr/bin/gcc or /usr/bin/g++,
> although this is discouraged as well, and should not crop up often (if
> at all), as doing this will make life very hard for cross-builders
>
> The idea here is not so much for our project in of it's self, it is to
> make sure we respect user-local configuration, or system-wide
> configuration, regardless of what compiler that is.
>
> We would like to propose the same approach for Fortran and Objective-C,
> but it seems that it is not as clear as the C/C++ convention. If someone
> could provide sane env-vars for these two, it would be very helpful.
>
> We should also make the following assumption -- the CC / CXX compiler
> will accept gcc compatible arguments, with only very minor changes that
> are gcc compatible as well (such as using -O3 rather then the
> meaningless -O6, etc). The clang compiler, for example, considers
> incompatible arguments with gcc a bug.
>
> Therefore, we would like to propose an update of Debian policy, to take
> effect after the Wheezy release.
>
> "4.9 Main building script: debian/rules"
> stating:
> -
> Hardcoded usage of CC or CXX (for example, CC=gcc) should be avoid and
> documented if necessary.
> Debian build tools must respect the CC and CXX variables if provided. If
> not, they shall default to /usr/bin/cc and /usr/bin/c++
> -
>
> If a rough consensus is reached it is our intent to make this into a
> release goal.
>
> Thanks,
> Sylvestre Ledru and Paul Tagliamonte
>
>
>
> --
> To UNSUBSCRIBE, email to 
> debian-devel-REQUEST@lists.**debian.org
> with a subject of "unsubscribe". Trouble? Contact
> listmas...@lists.debian.org
> Archive: 
> http://lists.debian.org/**503ce158.5090...@debian.org
>
>


-- 
James Michael DuPont
Member of Free Libre Open Source Software Kosova http://flossk.org
Saving wikipedia(tm) articles from deletion
http://SpeedyDeletion.wikia.com
Contributor FOSM, the CC-BY-SA map of the world http://fosm.org
Mozilla Rep https://reps.mozilla.org/u/h4ck3rm1k3

Re: Bug#686075: modemmanager shouldn't recommend usb-modeswitch, but suggest it

[Steve Langasek]

On Tue, Aug 28, 2012 at 04:05:46PM +0200, Michael Biebl wrote:
> On 28.08.2012 14:49, Marco d'Itri wrote:
> > On Aug 28, Michael Biebl  wrote:

> >> We don't have the infrastructure though, to do such hardware based
> >> installation requests, i.e. a system service which constantly monitors
> >> newly plugged in devices, has a database of devices mapping to packages,
> >> and a service running in the user session which can be signaled via the
> >> system service (e.g. via D-Bus) when such a hardware has been plugged
> >> in, and presents that to the user.
> > I think Ubuntu has something like this, udev would do most of the work.

> Interesting. Does anyone know more about that?

I think 'ubuntu-drivers-common' is the package you'd want to look at.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


-- 
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/20120828154009.gb24...@virgil.dodds.net

Re: Proposal: Making Debian compiler agnostic

[Alessandro Ghedini]

On Tue, Aug 28, 2012 at 05:18:48PM +0200, Sylvestre Ledru wrote:
> Hello,

Hi,

> Currently, it is the case that some packages are expecting gcc and g++
> to be the default and (almost) only C and C++ compilers. While it has
> been the case for the early days of the project, this assumption causes
> more and more issues for folks who want to use something _other_ then
> gcc or g++.

Just curious, do you have a list of such packages?

Cheers

-- 
perl -E '$_=q;$/= @{[@_]};and s;\S+;;eg;say~~reverse'


signature.asc
Description: Digital signature

Re: Proposal: Making Debian compiler agnostic

[Paul Tagliamonte]

On Tue, Aug 28, 2012 at 05:46:50PM +0200, Alessandro Ghedini wrote:
> On Tue, Aug 28, 2012 at 05:18:48PM +0200, Sylvestre Ledru wrote:
> > Hello,
> 
> Hi,
> 
> > Currently, it is the case that some packages are expecting gcc and g++
> > to be the default and (almost) only C and C++ compilers. While it has
> > been the case for the early days of the project, this assumption causes
> > more and more issues for folks who want to use something _other_ then
> > gcc or g++.
> 
> Just curious, do you have a list of such packages?

No, I've not built up such a list. I've seen it enough for me to recall
this edge-case. Most packages with a lone Makefile usually have:

  CC=gcc

Or so. Some other packages (I remember this from our gcc-4.6 --> 4.7
transition) have hard-coded gcc versions, even though it built fine with
4.7.

So, no, but it's present. Shouldn't take too much work to track this
down. This was something I was planning to do once the general feel was
that this was a good idea.

> 
> Cheers
> 
> -- 
> perl -E '$_=q;$/= @{[@_]};and s;\S+;;eg;say~~reverse'

Cheers,
  Paul

-- 
 .''`.  Paul Tagliamonte 
: :'  : Proud Debian Developer
`. `'`  4096R / 8F04 9AD8 2C92 066C 7352  D28A 7B58 5B30 807C 2A87
 `- http://people.debian.org/~paultag


signature.asc
Description: Digital signature

Re: Proposal: Making Debian compiler agnostic

[Mathieu Malaterre]

Salut,

On Tue, Aug 28, 2012 at 5:18 PM, Sylvestre Ledru  wrote:
> During our work, we have found a few interesting issues, and would like
> to push for some package policy changes for Jessie.

+1

> We would like to propose the same approach for Fortran and Objective-C,
> but it seems that it is not as clear as the C/C++ convention. If someone
> could provide sane env-vars for these two, it would be very helpful.

At least from cmake point of view, a user need to provide an env var
'FC' for the fortran compiler and sets 'FLAGS'.

Objective-C / Objective-C++ seems more hackish in cmake as it rely on
gcc/g++ to provide support for those languages.

HTH
-M


-- 
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/CA+7wUsw6kemFU5x_NNxfT1R5C3LG--GOyd+mzSLFAo0SN=m...@mail.gmail.com

Re: Proposal: Making Debian compiler agnostic

[Mathieu Malaterre]

On Tue, Aug 28, 2012 at 5:53 PM, Mathieu Malaterre  wrote:
> Salut,
>
> On Tue, Aug 28, 2012 at 5:18 PM, Sylvestre Ledru  wrote:
>> During our work, we have found a few interesting issues, and would like
>> to push for some package policy changes for Jessie.
>
> +1
>
>> We would like to propose the same approach for Fortran and Objective-C,
>> but it seems that it is not as clear as the C/C++ convention. If someone
>> could provide sane env-vars for these two, it would be very helpful.
>
> At least from cmake point of view, a user need to provide an env var
> 'FC' for the fortran compiler and sets 'FLAGS'.

Missing one 'F', it should read 'FFLAGS'

Sorry,
-M


-- 
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/ca+7wuszgg9jrlevwpa3_njmvjnc8vuo2rh35fzk+brvudf8...@mail.gmail.com

Re: Bug#684726: ITP: check_v46 -- Icinga / Nagios plugin for dual stacked (IPv4 / IPv6) hosts

[Don Armstrong]

On Tue, 28 Aug 2012, Christoph Anton Mitterer wrote:
> Well but many people disable this, because otherwise you get "tons" of
> stuff you don't need nor want.

People who disable recommends get to deal with any breakage they
generate by doing so. Promoting things which should be recommends to
depends because of this punishes those who are using the system in the
suggested manner.


Don Armstrong

-- 
We must realize that today's Establishment is the New George III.
Whether it will continue to adhere to his tactics, we do not know. If
it does, the redress, honored in tradition, is also revolution.
 -- William O. Douglas _Points of Rebellion_

http://www.donarmstrong.com  http://rzlab.ucr.edu


-- 
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/20120828160545.gh21...@teltox.donarmstrong.com

Re: Proposal: Making Debian compiler agnostic

[Sylvestre Ledru]

On 28/08/2012 17:46, Alessandro Ghedini wrote:

On Tue, Aug 28, 2012 at 05:18:48PM +0200, Sylvestre Ledru wrote:

Hello,

Hi,


Currently, it is the case that some packages are expecting gcc and g++
to be the default and (almost) only C and C++ compilers. While it has
been the case for the early days of the project, this assumption causes
more and more issues for folks who want to use something _other_ then
gcc or g++.

Just curious, do you have a list of such packages?


Actually, we are building it.
We have setup a parallel build infrastructure (wanna-buildd + buildd) 
with some changes (basically, making sure that packages will respect CC 
& CXX).
The rebuild for amd64 and i386 are currently ongoing (as you can 
imagine, it takes a while). We will share the result once we have them.


Sylvestre


--
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/503cf097.7060...@debian.org

Re: About the media types text/x-php and text/x-php-source

[Christoph Anton Mitterer]

On Tue, 2012-08-28 at 15:37 +0100, Ian Jackson wrote:
> > Then if there is a charset parameter, with a value that refers to
> > some known text character set, I think that one can assume that
> > the contents are encoded with this charset, thus can be displayed
> > as text.
> I don't think that follows at all.  It might just mean that the text
> in (say) the zipfile filenames is in whatever charset is specified.

I agree... the charset parameter does not necessarily imply that one has
plain text.
At least for HTTP it's not defined (at least not int RFC 2616) how the
charset= parameter is to be interpreted, and thus Ian's example is
absolutely valid.

Cheers,
Chris.


smime.p7s
Description: S/MIME cryptographic signature

Re: Proposal: Making Debian compiler agnostic

[Ben Hutchings]

On Tue, 2012-08-28 at 17:18 +0200, Sylvestre Ledru wrote:
> Hello,
> 
> This summer, during the Google Summer of Code (GSoC), we have been
> working to provide a way to rebuild the archive with a non-gcc compiler
> (in our case: clang).
> 
> Our project's intent is not to change the default compiler, just use a
> secondary compiler to generate more errors or warnings for package
> maintainers to be aware of. In most cases, keeping both compilers happy
> would result in higher quality code, something I think we can all get
> behind.
[...]
> We should also make the following assumption -- the CC / CXX compiler
> will accept gcc compatible arguments, with only very minor changes that
> are gcc compatible as well (such as using -O3 rather then the
> meaningless -O6, etc). The clang compiler, for example, considers
> incompatible arguments with gcc a bug.
[...]

Are all alternate compilers expected to implement gcc extensions?  Must
the code be changed to use appropriate '#ifdef __GNUC__' guards?  (And
what happens the next time gcc adds a new extension...?)

If a package fails to build with an alternate compiler (that is, it
correctly *uses* the compiler, but the compiler reports a fatal error),
is that considered a bug, and what severity does it have?

Ben.

-- 
Ben Hutchings
It is a miracle that curiosity survives formal education. - Albert Einstein


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

Re: Proposal: Making Debian compiler agnostic

[Paul Tagliamonte]

On Tue, Aug 28, 2012 at 09:27:23AM -0700, Ben Hutchings wrote:
> On Tue, 2012-08-28 at 17:18 +0200, Sylvestre Ledru wrote:
> > Hello,
> > 
> > This summer, during the Google Summer of Code (GSoC), we have been
> > working to provide a way to rebuild the archive with a non-gcc compiler
> > (in our case: clang).
> > 
> > Our project's intent is not to change the default compiler, just use a
> > secondary compiler to generate more errors or warnings for package
> > maintainers to be aware of. In most cases, keeping both compilers happy
> > would result in higher quality code, something I think we can all get
> > behind.
> [...]
> > We should also make the following assumption -- the CC / CXX compiler
> > will accept gcc compatible arguments, with only very minor changes that
> > are gcc compatible as well (such as using -O3 rather then the
> > meaningless -O6, etc). The clang compiler, for example, considers
> > incompatible arguments with gcc a bug.
> [...]
> 
> Are all alternate compilers expected to implement gcc extensions?  Must
> the code be changed to use appropriate '#ifdef __GNUC__' guards?  (And
> what happens the next time gcc adds a new extension...?)

clang does a fairly OK job with some of gcc's extentions. For now, I'm
likely to suggest we punt on this, and just ignore it. I don't know the
entire situation, but it's likely to be the case where it doesn't
implement all of them.

Remember, we saw ~8% failure on the last archive-wide clang rebuild[1]

> 
> If a package fails to build with an alternate compiler (that is, it
> correctly *uses* the compiler, but the compiler reports a fatal error),
> is that considered a bug, and what severity does it have?

I'd not consider a FTBFS with a non-critical compiler to be too high of
a severity, likely not RC. In fact, I'd likely only file a bug if the
issue is with the Debian packaging -- e.g. hardcoding CC or CXX in
d/rules or so, when the package builds fine without gcc otherwise.

For now, I think we're just interested in presenting people with this
information in the PTS & fixing low-hanging fruit when it's the case a
debian-local issue is causing the FTBFS.

Clearly, some upstreams (such as GNU projects, I'm guessing) wouldn't be
receptive to such changes, and I don't think it's right to try to
enforce this on them.

I'm open to your opinions on this :)

> 
> Ben.
> 
> -- 
> Ben Hutchings
> It is a miracle that curiosity survives formal education. - Albert Einstein

[1]: http://clang.debian.net/

Cheers,
  Paul

-- 
 .''`.  Paul Tagliamonte 
: :'  : Proud Debian Developer
`. `'`  4096R / 8F04 9AD8 2C92 066C 7352  D28A 7B58 5B30 807C 2A87
 `- http://people.debian.org/~paultag


signature.asc
Description: Digital signature

Re: Proposal: Making Debian compiler agnostic

[Sylvestre Ledru]

On 28/08/2012 18:27, Ben Hutchings wrote:

On Tue, 2012-08-28 at 17:18 +0200, Sylvestre Ledru wrote:

Hello,

This summer, during the Google Summer of Code (GSoC), we have been
working to provide a way to rebuild the archive with a non-gcc compiler
(in our case: clang).

Our project's intent is not to change the default compiler, just use a
secondary compiler to generate more errors or warnings for package
maintainers to be aware of. In most cases, keeping both compilers happy
would result in higher quality code, something I think we can all get
behind.

[...]

We should also make the following assumption -- the CC / CXX compiler
will accept gcc compatible arguments, with only very minor changes that
are gcc compatible as well (such as using -O3 rather then the
meaningless -O6, etc). The clang compiler, for example, considers
incompatible arguments with gcc a bug.

[...]

Are all alternate compilers expected to implement gcc extensions?  Must
the code be changed to use appropriate '#ifdef __GNUC__' guards?  (And
what happens the next time gcc adds a new extension...?)

With clang, most of them are implemented.
However, some of them are not. For example, nested functions:
http://clang.debian.net/status.php?version=3.1&key=EXPECTED_SEMILON
or some "Variable-length arrays" declarations:
http://clang.debian.net/status.php?version=3.1&key=VARIABLE_LENGTH_ARRAY
http://clang.debian.net/status.php?version=3.1&key=NON-POD

Most of the time, they are not implemented on purpose (one of the goal 
of clang is to be a replacement of gcc).

For more information:
http://clang.llvm.org/docs/UsersManual.html#c_unimpl_gcc

About Intel compilers or path64, I don't know how far they go.

I just would like to remind that our proposal is not about gcc vs clang 
but more about decouple Debian and gcc.


Sylvestre


--
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/503cf8fe.6070...@debian.org

Re: Proposal: Making Debian compiler agnostic

[Thomas Preud'homme]

Le mardi 28 août 2012 18:27:23, Ben Hutchings a écrit :
> 
> Are all alternate compilers expected to implement gcc extensions?  Must
> the code be changed to use appropriate '#ifdef __GNUC__' guards?  (And
> what happens the next time gcc adds a new extension...?)

I maintain tcc and it clearly doesn't support all the options gcc support. It 
emits a warning for all options it doesn't know. Does that sentence mean that 
the user defining CC to another compiler than gcc must make sure it support all 
options of gcc?

Best regards.


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

Re: Proposal: Making Debian compiler agnostic

[Russ Allbery]

Paul Tagliamonte  writes:
> On Tue, Aug 28, 2012 at 09:27:23AM -0700, Ben Hutchings wrote:

>> Are all alternate compilers expected to implement gcc extensions?  Must
>> the code be changed to use appropriate '#ifdef __GNUC__' guards?  (And
>> what happens the next time gcc adds a new extension...?)

> clang does a fairly OK job with some of gcc's extentions.

"Fairly OK" is a good way of putting it.  It's not reached the level of
"good," but it's probably workable for most practical purposes.  You will
get spurious warnings about some things, such as some of the __attribute__
tags, but I don't think I've seen a case where it flatly refuses to
compile something or miscompiles it.  That said, I've not used some of the
hairier gcc extensions.

> I'd not consider a FTBFS with a non-critical compiler to be too high of
> a severity, likely not RC. In fact, I'd likely only file a bug if the
> issue is with the Debian packaging -- e.g. hardcoding CC or CXX in
> d/rules or so, when the package builds fine without gcc otherwise.

I think it's fine to have those be normal bugs.  I would definitely not
want to make honoring CC an RC bug; not even hardening flags are an RC bug
(at least yet), and this is much less important.

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

Re: Restoring the removed e16 package

[Noel David Torres Taño]

> > > Find someone (preferably a team) to be the maintainers, prepare a
> > > suitable package, get someone to sponsor it, and reopen all the
> > > bugs which were closed by the removal.

I volunteer to help with the packaging work. I'm not a Debian Developer, so we 
would need sponsors anyway, but I can help with the technical detail of 
packaging itself. I'm also not a programmer, so can't help in fixing coding 
bugs. But I can (and I like) to help hunting bugs by using the software.

Regards

Noel Torres
er Envite


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

Re: Proposal: Making Debian compiler agnostic

[Michael Gilbert]

On Tue, Aug 28, 2012 at 12:53 PM, Paul Tagliamonte  wrote:
>> If a package fails to build with an alternate compiler (that is, it
>> correctly *uses* the compiler, but the compiler reports a fatal error),
>> is that considered a bug, and what severity does it have?
>
> I'd not consider a FTBFS with a non-critical compiler to be too high of
> a severity, likely not RC. In fact, I'd likely only file a bug if the
> issue is with the Debian packaging -- e.g. hardcoding CC or CXX in
> d/rules or so, when the package builds fine without gcc otherwise.

The usage of the term "must" and "shall" in the policy wording would
have the effect of making any such issues RC since those would become
policy violations.  Switching the the terms to "should" would probably
fix that.

Hardcoded usage of CC or CXX (for example, CC=gcc) should be avoid and
documented if necessary.
Debian build tools _should_ respect the CC and CXX variables if provided. If
not, they _should_ default to /usr/bin/cc and /usr/bin/c++

Best wishes,
Mike


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

Re: Proposal: Making Debian compiler agnostic

[Paul Tagliamonte]

On Tue, Aug 28, 2012 at 01:43:24PM -0400, Michael Gilbert wrote:
> On Tue, Aug 28, 2012 at 12:53 PM, Paul Tagliamonte  wrote:
> >> If a package fails to build with an alternate compiler (that is, it
> >> correctly *uses* the compiler, but the compiler reports a fatal error),
> >> is that considered a bug, and what severity does it have?
> >
> > I'd not consider a FTBFS with a non-critical compiler to be too high of
> > a severity, likely not RC. In fact, I'd likely only file a bug if the
> > issue is with the Debian packaging -- e.g. hardcoding CC or CXX in
> > d/rules or so, when the package builds fine without gcc otherwise.
> 
> The usage of the term "must" and "shall" in the policy wording would
> have the effect of making any such issues RC since those would become
> policy violations.  Switching the the terms to "should" would probably
> fix that.
> 
> Hardcoded usage of CC or CXX (for example, CC=gcc) should be avoid and
> documented if necessary.
> Debian build tools _should_ respect the CC and CXX variables if provided. 
> If
> not, they _should_ default to /usr/bin/cc and /usr/bin/c++

Indeed. However, this is a policy on d/rules, so hard-coding CC would be
RC, not a FTBFS on a non-gcc compiler.

However, perhaps you're right anyway.

> 
> Best wishes,
> Mike

Cheers,
  Paul

-- 
 .''`.  Paul Tagliamonte 
: :'  : Proud Debian Developer
`. `'`  4096R / 8F04 9AD8 2C92 066C 7352  D28A 7B58 5B30 807C 2A87
 `- http://people.debian.org/~paultag


signature.asc
Description: Digital signature

Re: About the media types text/x-php and text/x-php-source

[Vincent Lefevre]

On 2012-08-28 16:19:29 +0100, Ian Jackson wrote:
> *.php files should be recognised as text/x-php or text/x-php-source by
> our mime types file.
> 
> If Apache (or some other webserver) wants to automatically execute
> *.php files (whether the url referring to foo.php is is
> http://example.com/foo.php or http://example.com/foo) then that should
> be achieved by webserver configuration, and should not involve any
> changes to the filename-based mime type recognition system used for
> the rest of the system (eg mutt).

I agree.

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


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120828184803.gi19...@xvii.vinc17.org

Re: Proposal: Making Debian compiler agnostic

[Serge]

2012/8/28 Paul Tagliamonte wrote:

>> Just curious, do you have a list of such packages?
>
> No, I've not built up such a list. I've seen it enough for me to recall
> this edge-case. Most packages with a lone Makefile usually have:
>
>   CC=gcc

Notabug. :) I guess this is how it's supposed to be by Makefile design.
It's not a "hardcode". It's an option. You can always change it, just run:
  make CC=anothercc
(Note: not `CC=anothercc make`) It's a (known?) makefile feature. Those
variables in the beginning of a Makefile are often there just for that.

-- 
  Serge


-- 
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/CAOVenEo+=yt9nvkyajn7r9-ug8lgv3wksktaakj4mvphvux...@mail.gmail.com

Re: Minified javascript files

[Stefano Zacchiroli]

On Tue, Aug 28, 2012 at 11:56:53AM +0100, Ian Jackson wrote:
> Stefano Zacchiroli writes ("Re: Minified javascript files"):
> > The problem I see with it, is that it adds complexity to the judgement
> > of whether something is suitable for a source package or not (on all
> > actors involved: maintainer, ftp-masters, QA, bug reporters, etc.). With
> > something like that we'll have 3 cases:
> > 
> > - DFSG-free source[1] -> stay in the tarball, not hidden
> > - non DFSG-free "binary" -> must be removed, via repacking
> > - "binary" generated from DFSG-free source available elsewhere in the
> >   archive -> stay in the tarball, hidden at the dpkg-source level
> 
> That's not what I was proposing.  I was proposing that we would treat
> your 2nd and 3rd points identically.  They would then be in our
> archive in the .orig.tar.gz files.

Right, that's, strictly speaking, not what you proposed. But it seems to
me that to support the argument "it's not SC violation because the
source is available in a different package", you do need to perform such
a distinction.

Anyway, the most important part seems to be your ideological[1]
question:

> If this is not ideologically[1] acceptable

The point here is whether having non-free material, which is in
distributed tarballs but hidden by dpkg-source, would constitute
inclusion of non-free material in what we call Debian. (Of course we're
talking about "main" here.)

Personally, I wouldn't consider that acceptable.

Even if I were ready to accept the idea that "hidden for any reasonable
purpose" non-free material could be part of Debian tarballs (and I'm
not), I wouldn't consider dpkg-source hiding good enough. The reason is
that what to do with a .orig.tar.gz file --- invoking dpkg-source on it
--- is obvious to anyone with Debian knowledge, but it is obscure to
anyone else. A random *nix user with no Debian knowledge would just open
it up, find non-free material, and be induced to conclude that it is
part of Debian.

For DFSG-related purposes dpkg-source hiding is just not enough, IMO.
(Thought it'd still be fine for the 3rd case above.)

Cheers.


[1] same footnote of yours:
> [1] NB I do not mean to use "ideological" in a pejorative way.  I am
> very comfortable with the idea that Debian might make decisions based
> on ideology.  The root question being discussed here is IMO
> essentially ideological.

-- 
Stefano Zacchiroli  . . . . . . .  z...@upsilon.cc . . . . o . . . o . o
Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o
Debian Project Leader . . . . . . @zack on identi.ca . . o o o . . . o .
« the first rule of tautology club is the first rule of tautology club »


signature.asc
Description: Digital signature

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

[Serge]

2012/8/20 Noel David Torres Taño wrote:

> Have you all minded that there are several *different* use cases?
>
> * Laptop user going here and there, sometimes with Wireless, sometimes
> with cable, sometimes with USB stick
> * Desktop user with home ADSL
> * Server with several connections
>
> Each use case has its own needs, and its own best tools.
>
> No ifupdown nor NM will fit them all, ever.

It should not be that hard to fit them all.

All connections I can think of belong to one of two categories:
1. Permanent connections. Those are "setup-and-forget" connections.
Typical for servers and wired desktops. Can be managed with ifupdown.
2. Temporary connections. Those are "use-once-and-forget" connections
(e.g. wifi in airport/hotel). Typical for mobile/moveable devices.
They're different from #1 because they should not be stored in configs.

So one tool supporting both of these connections will suit them all. :)
It does not matter what tool it is. It can be some kind of ifupdown GUI
with temporary connections support (just connect without storing configs).
Or it can be NetworkManager, that uses some ifupdown plugin to store
permanent connections.

For advanced users/developers/hackers there's already a tool that fits
them all - console. They can manually configure permanent connections
there. And they can manually run temporary connections there too.
It's easy, usually one command is enough to do that. For example:
DHCP: dhclient eth0
DSL: pppd plugin rp-pppoe.so eth0 user  password 
defaultroute usepeerdns
VPN: pppd defaultroute user  password  pty "pptp
12.34.56.78 --nolaunchpppd"
WIFI: wpa_supplicant -c /tmp/mynetwork.conf
I was able to bring up GPRS USB stick with one (long) pppd command once,
but can't find it right now.

I mean, there's already a "tool" (console) that suit many "smart" users.
To "fit them all" the only thing missing is some GUI with ifupdown support
for "regular" users. But it's not impossible to write one.

PS: I'm dreaming about writing such a tool for a few years already
(something simple, winetricks-like GUI bash script for creating
temporaty connections and then optionally storing them permanently),
just had no time to actually do that, directly running dhclient, pppd
or wpa_supplicant was usually enough for me. Maybe someone else
will eventually write one...

PPS: writing here in case someone else with a lot of free time may
like the idea and implement it. :)

-- 
  Serge


--
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/caovenerq_u4olj+heka3rz0xvsxrtsbbpod-_mc0k33zff+...@mail.gmail.com

Re: Proposal: Making Debian compiler agnostic

[Paul Tagliamonte]

On Tue, Aug 28, 2012 at 10:27:18PM +0300, Serge wrote:
> 2012/8/28 Paul Tagliamonte wrote:
> 
> >> Just curious, do you have a list of such packages?
> >
> > No, I've not built up such a list. I've seen it enough for me to recall
> > this edge-case. Most packages with a lone Makefile usually have:
> >
> >   CC=gcc
> 
> Notabug. :) I guess this is how it's supposed to be by Makefile design.

Is a bug :)

> It's not a "hardcode". It's an option. You can always change it, just run:
>   make CC=anothercc
> (Note: not `CC=anothercc make`) It's a (known?) makefile feature. Those
> variables in the beginning of a Makefile are often there just for that.

It won't respect exported env-vars:

[tag@chayot:~]$ cat Makefile
CRUFT =  foo
KRUFT ?= bar

all:
@echo $(CRUFT)
@echo $(KRUFT)


[tag@chayot:~]$ make
foo
bar
[tag@chayot:~]$ make CRUFT=bar
bar
bar
[tag@chayot:~]$ make KRUFT=foo
foo
foo
[tag@chayot:~]$ CRUFT=bar make
foo
bar
[tag@chayot:~]$ KRUFT=foo make
foo
foo

> 
> -- 
>   Serge
> 
> 
> -- 
> 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/CAOVenEo+=yt9nvkyajn7r9-ug8lgv3wksktaakj4mvphvux...@mail.gmail.com
> 

-- 
 .''`.  Paul Tagliamonte 
: :'  : Proud Debian Developer
`. `'`  4096R / 8F04 9AD8 2C92 066C 7352  D28A 7B58 5B30 807C 2A87
 `- http://people.debian.org/~paultag


signature.asc
Description: Digital signature

Re: Proposal: Making Debian compiler agnostic

[Henrique de Moraes Holschuh]

On Tue, 28 Aug 2012, Paul Tagliamonte wrote:
> Clearly, some upstreams (such as GNU projects, I'm guessing) wouldn't be
> receptive to such changes, and I don't think it's right to try to
> enforce this on them.

Those quite often use automake for the build system.  Automake is supposed
to be compiler-agnostic.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh


-- 
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/20120828194826.ga16...@khazad-dum.debian.net

Archive-wide rebuilds using scan-build (was: Re: Proposal: Making Debian compiler agnostic)

[Bernd Zeimetz]

Hi,

> This summer, during the Google Summer of Code (GSoC), we have been
> working to provide a way to rebuild the archive with a non-gcc compiler
> (in our case: clang).
> 
> Our project's intent is not to change the default compiler, just use a
> secondary compiler to generate more errors or warnings for package
> maintainers to be aware of. In most cases, keeping both compilers happy
> would result in higher quality code, something I think we can all get
> behind.

I think it would be great if we could build all packages with scan-build
automatically - as soon as there is some way to specify a different compiler,
this should not be too hard. It might even be enough to use gcc/g++ as compiler
in scan-build. I'm running some of my favourite packages trough it, which makes
upstream happy (well or not, if some new errors show up again :)). So making all
packages respect CC/CXX would be good to have not only to build them with
different compilers.

Cheers and thanks for your work,

Bernd
-- 
 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/503d2138.6010...@bzed.de

Re: Archive-wide rebuilds using scan-build

[Sylvestre Ledru]

Le 28/08/2012 21:51, Bernd Zeimetz a écrit :
> Hi,
>
>> This summer, during the Google Summer of Code (GSoC), we have been
>> working to provide a way to rebuild the archive with a non-gcc compiler
>> (in our case: clang).
>>
>> Our project's intent is not to change the default compiler, just use a
>> secondary compiler to generate more errors or warnings for package
>> maintainers to be aware of. In most cases, keeping both compilers happy
>> would result in higher quality code, something I think we can all get
>> behind.
> I think it would be great if we could build all packages with scan-build
> automatically - as soon as there is some way to specify a different compiler,
> this should not be too hard. It might even be enough to use gcc/g++ as 
> compiler
> in scan-build. I'm running some of my favourite packages trough it, which 
> makes
> upstream happy (well or not, if some new errors show up again :)). So making 
> all
> packages respect CC/CXX would be good to have not only to build them with
> different compilers.
You just spoiled one of my todo list item. ;)

For those who don't know scan-build, it is a free static analyzer
distributed with clang.
It gives nice feedbacks on common errors which cannot be find by
"normal" checks by compiler.
For example, scan-build on llvm & clang:
http://lbalbalba.x90x.net/clang-analyzer/llvm-clang/r162646/

> Cheers and thanks for your work,
Thanks for your feedback.

Sylvestre


-- 
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/503d234b.6000...@debian.org

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

[Ben Hutchings]

On Tue, 2012-08-28 at 22:41 +0300, Serge wrote:
> 2012/8/20 Noel David Torres Taño wrote:
> 
> > Have you all minded that there are several *different* use cases?
> >
> > * Laptop user going here and there, sometimes with Wireless, sometimes
> > with cable, sometimes with USB stick
> > * Desktop user with home ADSL
> > * Server with several connections
> >
> > Each use case has its own needs, and its own best tools.
> >
> > No ifupdown nor NM will fit them all, ever.
> 
> It should not be that hard to fit them all.
> 
> All connections I can think of belong to one of two categories:
> 1. Permanent connections. Those are "setup-and-forget" connections.
> Typical for servers and wired desktops. Can be managed with ifupdown.
> 2. Temporary connections. Those are "use-once-and-forget" connections
> (e.g. wifi in airport/hotel). Typical for mobile/moveable devices.
> They're different from #1 because they should not be stored in configs.
[...]

I don't think there is this hard line between 'permanent' and
'temporary' connections.  Hotel wifi certainly isn't
'use-once-and-forget'.  I should be able to configure it when I arrive
and have it remembered as long as I stay.  But I could imagine having a
'temporary' checkbox that causes it to expire if unused for a week.

I also have multiple wired Ethernet configurations in Network Manager,
and choose which one I want after inserting the cable.

There are several other categories of dynamic connections, including:
3. VPN tunnels (server end)
4. Connections to a VM

Most likely these should not be managed by either ifupdown or NM.

Ben.

-- 
Ben Hutchings
It is a miracle that curiosity survives formal education. - Albert Einstein


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

Re: [proposal] use xz compression for Debian package by default

[Adam Borowski]

On Tue, Aug 28, 2012 at 12:56:47PM +0200, Vincent Lefevre wrote:
> Before wondering whether PNG files should have an additional
> compression level, is there any reason why a better PNG compression
> isn't used in the first place? For instance, "optipng -o9" tries
> various parameters and keeps the best one.

optipng can improve only earlier stages of PNG format (ARGB->paletted, pixel
filters), its deflate implementation is pretty bad.  You'd want to use it
together with advpng (package advancecomp) which attacks the deflate stage
better:
optipng -o4 -i0 -fix $* && advpng -z4 $*

(Optimizations above -o4 affect deflate only, advpng is scared by interlaced
images and files with junk after PNG data.)


As per my tests, other combinations of PNG optimizers give worse results,
and in some cases (PNGOUT, fortunately not in Debian) even destroy images.
It might be possible to compress files even better by tossing away dubious
chunks added by some editors (Adobe stuff is especially notorious), but
that can be argued to be data loss of sorts.

-- 
Copyright and patents were never about promoting culture and innovations;
from the very start they were legalized bribes to give the king some income
and to let businesses get rid of competition.  For some history, please read
https://en.wikipedia.org/wiki/Statute_of_Monopolies_1623


-- 
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/20120828210353.ga9...@angband.pl

Re: [b-d][falla] acl2

[Peter Palfrader]

On Tue, 28 Aug 2012, Camm Maguire wrote:

> > On Mon, 27 Aug 2012, Camm Maguire wrote:
> >
> >> Greetings!  This is to build by hand in order to work around an
> >> unreproducible fault on fasch.

Installed.  Note that packages that do not build on our autobuilders are
probably RC-buggy.  You can use falla to find the issue, but it is not
meant as a resource to work around your-package-and-buildds-issues.

Cheers,
-- 
   |  .''`.   ** Debian **
  Peter Palfrader  | : :' :  The  universal
 http://www.palfrader.org/ | `. `'  Operating System
   |   `-http://www.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/20120828213215.go5...@anguilla.noreply.org

Re: [php-maint] Bug#670945: About the media types text/x-php and text/x-php-source

[Charles Plessy]

Dear Ondřej and everybody,

I would like to keep separate the two following issues.

 1) Whether or not to give a private media type to PHP files in Debian, and
if yes, which one.

 2) Provide a smooth upgrade to our users who use Apache's mod_negociation in a 
way
that is different to what is recommended in PHP (where the FAQ suggests to 
associate
the media type "text/html" to .php files).

http://www.php.net/manual/en/faq.installation.php#faq.installation.apache.multiviews

Point 2) can be solved by adding two lines (plus explanatory comments) in 
/etc/apache2/mods-available/php5.conf (http://bugs.debian.org/670945#26).

Ondřej, I would appreciate if you solved #670945 this way.  I understand that it
puts the work burden on your shoulders and that php5 is a much heavier package
than mime-support, but I think that it is the cleanest solution.  For the moment
I have not received any message saying that a media type needs to be provided by
mime-support in order for PHP to work in other contexts.

To everybody:

we are periodically reminded that the core teams in Debian are dramatically 
understaffed.
Given the number of Debian systems serving content to the world using PHP, 
please consider
that the PHP maintainers team is one of them.  They need your help !  The time 
you will
give will directly help Debian to stay among the top distributions.

Have a nice day,

-- 
Charles Plessy
Tsurumi, Kanagawa, Japan


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

Re: Proposal: Making Debian compiler agnostic

[Paul Wise]

Sounds good, but I've a concern about the technical implementation of this:

We explicitly moved away from having debian/rules depend on
environment variables for compiler flags, shouldn't we be doing the
same for compiler choice also? Perhaps we could use this instead:

dpkg-buildflags --get CC
dpkg-buildflags --get CXX
dpkg-buildflags --get FC

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


-- 
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/caktje6etghodm7ye-scuv_vs1bgx165eipqqbulff8psjzm...@mail.gmail.com

Re: Proposal: Making Debian compiler agnostic

[brian m. carlson]

On Tue, Aug 28, 2012 at 10:26:37AM -0700, Russ Allbery wrote:
> Paul Tagliamonte  writes:
> > On Tue, Aug 28, 2012 at 09:27:23AM -0700, Ben Hutchings wrote:
> 
> >> Are all alternate compilers expected to implement gcc extensions?  Must
> >> the code be changed to use appropriate '#ifdef __GNUC__' guards?  (And
> >> what happens the next time gcc adds a new extension...?)

clang #defines __GNUC__ but isn't completely compatible.  In order to
test if it's really GCC, you have to check that __clang__ isn't defined.
As you can see, this quickly becomes problematic if one must check all
the things that the compiler is not to see what the compiler is.

> > clang does a fairly OK job with some of gcc's extentions.
> 
> "Fairly OK" is a good way of putting it.  It's not reached the level of
> "good," but it's probably workable for most practical purposes.  You will
> get spurious warnings about some things, such as some of the __attribute__
> tags, but I don't think I've seen a case where it flatly refuses to
> compile something or miscompiles it.  That said, I've not used some of the
> hairier gcc extensions.

I have some code that uses the __builtin_ia32_* functions for intrinsics
that clang refuses to compile because it has different, incompatible
intrinsics (#653256).  Since clang insists on using __GNUC__, it's
difficult to detect whether the compiler really is GCC or whether it's a
broken clone (which could be clang or something entirely different).
clang upstream does not consider this incompatibility a bug; I do.

-- 
brian m. carlson / brian with sandals: Houston, Texas, US
+1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only
OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187


signature.asc
Description: Digital signature

Re: Proposal: Making Debian compiler agnostic

[Russ Allbery]

"brian m. carlson"  writes:
> On Tue, Aug 28, 2012 at 10:26:37AM -0700, Russ Allbery wrote:

>> "Fairly OK" is a good way of putting it.  It's not reached the level of
>> "good," but it's probably workable for most practical purposes.  You
>> will get spurious warnings about some things, such as some of the
>> __attribute__ tags, but I don't think I've seen a case where it flatly
>> refuses to compile something or miscompiles it.  That said, I've not
>> used some of the hairier gcc extensions.

> I have some code that uses the __builtin_ia32_* functions for intrinsics
> that clang refuses to compile because it has different, incompatible
> intrinsics (#653256).  Since clang insists on using __GNUC__, it's
> difficult to detect whether the compiler really is GCC or whether it's a
> broken clone (which could be clang or something entirely different).
> clang upstream does not consider this incompatibility a bug; I do.

Yeah, I have similar messes in some of my code.

/*
 * LLVM and Clang pretend to be GCC but don't support all of the __attribute__
 * settings that GCC does.  For them, suppress warnings about unknown
 * attributes on declarations.  This unfortunately will affect the entire
 * compilation context, but there's no push and pop available.
 */
#if !defined(__attribute__) && (defined(__llvm__) || defined(__clang__))
# pragma GCC diagnostic ignored "-Wattributes"
#endif

(Note that Clang does support #pragma GCC diagnostic, so it definitely
does support a bunch of the GCC extensions.)

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

Processed: Re: Please revert original bug title

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> unmerge 652011
Bug #652011 [debian-policy] consider dropping the separation between /bin and 
/usr/bin, and /lib and /usr/lib
Bug #686143 [debian-policy] debian-policy: FHS requirements on "essential" 
binaries cannot be well, defined at distro level
Disconnected #652011 from all other report(s).
> retitle 652011 general: Repeated pattern of FHS violation: Dependencies of 
> /sbin and /bin, belong in /lib
Bug #652011 [debian-policy] consider dropping the separation between /bin and 
/usr/bin, and /lib and /usr/lib
Changed Bug title to 'general: Repeated pattern of FHS violation: Dependencies 
of /sbin and /bin, belong in /lib' from 'consider dropping the separation 
between /bin and /usr/bin, and /lib and /usr/lib'
> reassign 652011 general
Bug #652011 [debian-policy] general: Repeated pattern of FHS violation: 
Dependencies of /sbin and /bin, belong in /lib
Bug reassigned from package 'debian-policy' to 'general'.
No longer marked as found in versions debian-policy/3.9.1.0.
Ignoring request to alter fixed versions of bug #652011 to the same values 
previously set
> # effectively unresolvable as a general bug; to further pursue this would
> # require specific bugs filed against specific packages
> close 652011
Bug #652011 [general] general: Repeated pattern of FHS violation: Dependencies 
of /sbin and /bin, belong in /lib
Marked Bug as done
> thanks
Stopping processing here.

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

Re: Minified javascript files

[Thomas Goirand]

On 08/29/2012 03:40 AM, Stefano Zacchiroli wrote:
> The point here is whether having non-free material, which is in
> distributed tarballs but hidden by dpkg-source, would constitute
> inclusion of non-free material in what we call Debian. (Of course we're
> talking about "main" here.)
>
> Personally, I wouldn't consider that acceptable.
>   
I agree. And with latest addition in uscan, we have no excuse anymore.

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/503db18b.20...@debian.org

Re: Proposal: Making Debian compiler agnostic

[Vincent Danjean]

Le 29/08/2012 06:33, Russ Allbery a écrit :
> /*
>  * LLVM and Clang pretend to be GCC but don't support all of the __attribute__
>  * settings that GCC does.  For them, suppress warnings about unknown
>  * attributes on declarations.  This unfortunately will affect the entire
>  * compilation context, but there's no push and pop available.
>  */
> #if !defined(__attribute__) && (defined(__llvm__) || defined(__clang__))
> # pragma GCC diagnostic ignored "-Wattributes"
> #endif

There exists some kind of push/pop but I'm not sure it is relevant is
your context nor that llvm/clang support them.
  In one of my projects where I include a header file that produces
warnings (with #warning ...) and that adds the "deprecated" attribute
to some function, I use:

#pragma GCC diagnostic push
#  pragma GCC diagnostic ignored "-Wcpp"
#  define CL_USE_DEPRECATED_OPENCL_1_1_APIS
#  include 
#pragma GCC diagnostic pop

#pragma GCC diagnostic ignored "-Wdeprecated-declarations"

Note that the "-Wdeprecated-declarations" is not in the push/pop
section because it needs to be active at the time that deprecated
functions are used, not at the time that deprecated functions are
declared with their attribute (ie in )

  Regards,
Vincent

-- 
Vincent Danjean   GPG key ID 0x9D025E87 vdanj...@debian.org
GPG key fingerprint: FC95 08A6 854D DB48 4B9A  8A94 0BF7 7867 9D02 5E87
Unofficial pkgs: http://moais.imag.fr/membres/vincent.danjean/deb.html
APT repo:  deb http://people.debian.org/~vdanjean/debian unstable main


-- 
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/503db6fb.1040...@free.fr

usacn enhancement take 2: --repack-compression (Was: [proposal] use xz compression for Debian package by default)

[Andreas Tille]

Hi,

as you might have noticed I implemented some way to teach uscan
excluding certain files from upstream tarball to make it dfsg compatible
(see bug #685787).  In the previous discussion about this also the topic
of compression came up[1].  I have the following proposal:  Add an option

   --repack-compression 

to uscan which works as follows:

  1. If (and only if) there is some reason for repackaging (which
 could be given by --repack or mentioning Files-Excluded field
 in debian/copyright) the mentioned compression method is used.
 (in other words: --repack-compression will be ignored if there
 is no reason to touch the tarball)

  2. compression could be either gz, bz2 or xz (feel free to propose
 others)  The repackaging is done using

   tar -c --auto-compress -f _.orig.tar.

 (so if you propose other compression methods please make sure
 these are working with tar's --auto-compress option.)

  3. Given the fact that this option would give a chance to change
 the compression method I'm tempted to change the default
 compression method for --repack (and Files-Excluded) to xz.
 I'm aware that this is a change of the known behaviour of
 --repack but that's the reason why I'm posting in this thread
 which is proposing to change some defaults.  You can restore
 the old behaviour by

uscan --repack --repack-compression gz

  4. I do not regard a configuration variable for
 /etc/devscripts.conf as a good idea because running uscan on
 different computers should end up in a comparable result
 independently from local configuration (feel free to prove me
 wrong here)

  5. If the repackaging is done because of Files-Excluded some
 uscan tries to undirty the tarball because this makes somehow
 sense and we are breaking MD5 sum compatibility anyway.  Do
 you think this undirtying should also be tried when only using
 --repack option?

BTW, I'd be happy if more people would test the removal using
Files-Excluded with the new uscan which is available in Git[2].

Kind regards

   Andreas.

[1] http://lists.debian.org/debian-devel/2012/08/msg00402.html
[2] 
http://anonscm.debian.org/gitweb/?p=users/tille/devscripts.git;a=blob;f=scripts/uscan.pl;hb=HEAD

-- 
http://fam-tille.de


-- 
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/20120829064443.ga22...@an3as.eu

uscan enhancement take 3: script hook

[Andreas Tille]

Hi,

as you might have noticed I implemented some way to teach uscan
excluding certain files from upstream tarball to make it dfsg compatible
(see bug #685787).  When trying to get rid of some get-orig-source
scripts I noticed that besided some file removals I need to execute some
extra code.  This is basically fetching some extra files like sources
for documentation, uncompressed JS files etc from external sources
(http, VCS).

IMHO this could be done quite simple if we would enable uscan to call a
script say debian/uscan.hook (feel free to propose a better name).

The rules for applying the hook would be very similar to the
Files-Excluded behaviour (and would also involve the compression
suggestion I had given in my previous mail).  In short:  If such hook is
found a repackaging of an upstream tarball is done and uscan tries hard
to create a "reasonable" tarball with features of potential undirtying
and naming conventions as given in DevRef §6.7.8.2.

BTW, I'd be happy if more people would test the file removal feature
using Files-Excluded with the new uscan which is available in Git[1].

Kind regards

   Andreas.

[1] 
http://anonscm.debian.org/gitweb/?p=users/tille/devscripts.git;a=blob;f=scripts/uscan.pl;hb=HEAD

-- 
http://fam-tille.de


-- 
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/20120829065509.gb22...@an3as.eu