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 interpreter
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.
>
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 compressi
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/.
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/
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+Downloa
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 direc
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 inter
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
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 th
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, w
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
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 obvio
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 P
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, s
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:
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 probl
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
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 giv
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 wa
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
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.
>
.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 hi
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 whic
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
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/pla
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
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,
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 Ma
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
On Tue, Aug 28, 2012 at 12:10:18PM +0900, Hideki Yamane wrote:
> --
> conclusion (rest)
> --
> I recommend to use xz ***by default*** (with approp
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
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)
> >
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 o
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
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
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 fo
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 Led
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
> >> ne
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
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
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 n
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
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
depen
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 d
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 fol
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 compile
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 c
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 no
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 doe
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...?
> > > 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
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
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
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
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 b
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: mainta
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
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:
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 compi
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 war
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
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 us
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
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 u
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
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
dp
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__'
"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 so
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 le
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.)
>
> Personal
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 cont
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
--repa
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
74 matches
Mail list logo
