On Thu, 30 Aug 2012 00:32:57 +0300
Timo Juhani Lindfors wrote:
> Christoph Anton Mitterer writes:
> > Each package depends on exactly what it needs to work and recommends
> > anything which adds e.g. additional features but doesn't cause
> > non-graceful breakage if missing.
>
> I guess that re
Subject: ITP: ted -- lightweight .DOC editor
Package: wnpp
Version: 2.22; reported 2012-01-04
Severity: wishlist
* Package name : ted
Version : 2.22
Upstream Author : Mark de Does
* URL : http://nllgg.nl/Ted/
* License : GPL
Description : lightweight .DOC editor
This was included in previous ver
On Thu, 2012-08-30 at 11:44 +0800, Thomas Goirand wrote:
> On 08/30/2012 07:15 AM, Marco d'Itri wrote:
> > nowadays it is clear that
> > the upstream maintainers of various stuff do not support a standalone
> > /usr mounted by the init scripts: if /usr is a standalone file system
> > then it must
On Wed, 2012-08-29 at 22:25 -0300, Henrique de Moraes Holschuh wrote:
> On Thu, 30 Aug 2012, Marco d'Itri wrote:
> > On Aug 30, Michael Biebl wrote:
> > > The obvious way is to not use a separate /usr anymore or simply mount
> > > /usr via the initramfs.
> > >
> > > Wasn't there a patch for initr
On 08/30/2012 07:15 AM, Marco d'Itri wrote:
> nowadays it is clear that
> the upstream maintainers of various stuff do not support a standalone
> /usr mounted by the init scripts: if /usr is a standalone file system
> then it must be mounted in the initramfs.
>
Instead of advertizing about (ho
On Thu, 30 Aug 2012, Marco d'Itri wrote:
> On Aug 30, Michael Biebl wrote:
> > The obvious way is to not use a separate /usr anymore or simply mount
> > /usr via the initramfs.
> >
> > Wasn't there a patch for initramfs-tools floating around doing that?
> Yes, there is one but the maintainer has
m...@linux.it (Marco d'Itri) writes:
> On Aug 30, Russ Allbery wrote:
>> And yet, when we discussed this just a little bit ago, several people
>> asked to keep the distinction because, for them, it provides value.
> A few people ask for silly things all the time, but this in itself is
> not a g
On Aug 30, Russ Allbery wrote:
> And yet, when we discussed this just a little bit ago, several people
> asked to keep the distinction because, for them, it provides value.
A few people ask for silly things all the time, but this in itself is
not a good enough reason to satisfy their requests.
Michael Biebl writes:
> On 30.08.2012 01:45, brian m. carlson wrote:
>> Upstream maintainers of various stuff also refuse to provide man pages.
>> Debian does not always do what upstream wants.
> Providing man pages (if written well) does provide value, shuffling bits
> around in the file system
On 30.08.2012 01:45, brian m. carlson wrote:
> On Thu, Aug 30, 2012 at 01:15:32AM +0200, Marco d'Itri wrote:
>> Fellow developers, please do not waste your time moving stuff to /lib:
>> it's a task both endless and futile because nowadays it is clear that
>> the upstream maintainers of various st
On Thu, Aug 30, 2012 at 01:15:32AM +0200, Marco d'Itri wrote:
> Fellow developers, please do not waste your time moving stuff to /lib:
> it's a task both endless and futile because nowadays it is clear that
> the upstream maintainers of various stuff do not support a standalone
> /usr mounted by
On Aug 30, Michael Biebl wrote:
> The obvious way is to not use a separate /usr anymore or simply mount
> /usr via the initramfs.
>
> Wasn't there a patch for initramfs-tools floating around doing that?
Yes, there is one but the maintainer has not applied or rejected it
so far.
Fellow develope
On Thu, Aug 30, 2012 at 01:02:39AM +0200, Michael Biebl wrote:
> On 30.08.2012 00:31, Peter Samuelson wrote:
> >
> > [Russ Allbery]
> >> All PAM modules are installed under /lib, because that's the path
> >> used by libpam to load them. However, I don't think the vast
> >> majority of PAM modules
Michael Biebl writes:
> Imho moving pam modules around is just wasted (maintainer) time.
> A much more sensible approach is to just lift the /-vs-/usr restriction.
We just had a long discussion about this. I think it's fairly safe to say
that while there are a number of people who think the dis
On 30.08.2012 00:31, Peter Samuelson wrote:
>
> [Russ Allbery]
>> All PAM modules are installed under /lib, because that's the path
>> used by libpam to load them. However, I don't think the vast
>> majority of PAM modules could be considered critical for early boot
>> or need to be usable withou
On Thu, 2012-08-30 at 07:16 +0900, Charles Plessy wrote:
> A type is a subclass of another type if any instance of the first type is
> also an instance of the second. For example, all image/svg files are also
> text/xml, text/plain and application/octet-stream files. Subclassing is
> about
>
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...?)
As I've pointed out, clang (a
[Russ Allbery]
> All PAM modules are installed under /lib, because that's the path
> used by libpam to load them. However, I don't think the vast
> majority of PAM modules could be considered critical for early boot
> or need to be usable without /usr mounted
It seems pam already looks in both /
[Copy sent to maintainers of mime-support, shared-mime-info, file and php5, as
an invitation to participate to the discussion.]
Le Sun, Aug 26, 2012 at 01:27:51PM -0700, Ben Hutchings a écrit :
> On Sun, 2012-08-26 at 19:55 +0200, Christoph Anton Mitterer wrote:
> >
> > With things like SVG it's
Hey Ondřej.
On Wed, 2012-08-29 at 11:11 +0200, Ondřej Surý wrote:
> your text is very hard to read and parse.
Sorry O:-)
Below you find the texts as I would have written them.
1) Especially the README.Debian text is much more elaborate.
Why? What we try with the whole issue here is to prevent ou
* Jakub Wilk (jw...@debian.org) wrote:
> I analysed all binaries and libraries shipped in /bin, /sbin and
> /lib to find stuff that requires libraries from /usr/lib. Please see
> the attachments for results (unstable, i386).
[snip]
> Eric Dorland
>libpam-p11
[snip]
I think PAM modules ha
Don Armstrong writes:
> Graceful breakage isn't what policy requires; it's whether the package
> is a requirement for a significant[1] amount of functionality. [That
> said, specifically indicating that a Recommends: or Suggests: package is
> required to use certain optional functionality in docu
On Wed, 29 Aug 2012, Christoph Anton Mitterer wrote:
> On 08/28/2012 06:05 PM, Don Armstrong wrote:[0]
> > 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
Jakub Wilk writes:
> I analysed all binaries and libraries shipped in /bin, /sbin and /lib to
> find stuff that requires libraries from /usr/lib. Please see the
> attachments for results (unstable, i386).
> Russ Allbery
>libpam-afs-session
>libpam-heimdal
>libpam-krb5
>libpam-sh
Christoph Anton Mitterer writes:
> Each package depends on exactly what it needs to work and recommends
> anything which adds e.g. additional features but doesn't cause
> non-graceful breakage if missing.
I guess that really depends on what non-graceful breakage means. I
personally assume that no
I analysed all binaries and libraries shipped in /bin, /sbin and /lib to
find stuff that requires libraries from /usr/lib. Please see the
attachments for results (unstable, i386).
--
Jakub Wilk
/bin/gaffitter /usr/lib/i386-linux-gnu/libstdc++.so.6
/bin/ping6 /usr/lib/i386-linux-gnu/libcry
On Wed, 2012-08-29 at 14:11 +0200, Bernd Zeimetz wrote:
> 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.
Uhm why?
Greetings!
Peter Palfrader writes:
> 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 ou
Package: wnpp
Severity: wishlist
Owner: "Sébastien Villemot"
* Package name: slicot
Version : 5.0+20101122
Upstream Author : Vasile Sima
* URL : http://www.slicot.org/
* License : GPL-2+
Programming Lang: Fortran 77
Description : numerical algorithms f
Package: wnpp
Severity: wishlist
Owner: Juhani Numminen
* Package name: fortuner
Version : 0.4.0
Upstream Author : Juhani Numminen
* URL : https://github.com/jnumm/fortuner
* License : GPLv3+
Programming Lang: C, C++
Description : Modernization of clas
On Wed, Aug 29, 2012 at 12:11:02PM -0400, Joey Hess wrote:
>Steve McIntyre wrote:
>> People have worried about it, but I think the consensus from DebConf
>> is that we don't want to be hampered in our own development by
>> considering external users
>
>How are "external users" different from "users
Steve McIntyre wrote:
> People have worried about it, but I think the consensus from DebConf
> is that we don't want to be hampered in our own development by
> considering external users
How are "external users" different from "users"?
--
see shy jo
signature.asc
Description: Digital signature
Marco wrote:
>On Aug 29, Guillem Jover wrote:
>
>> I thought this was already the consensus, and the only dissenting
>> opinion was that the base system should still be using gzip so that
>> foreign non-Debian systems can unpack it w/o requiring to build or
>> install xz beforehand.
>I am not sure
Le mercredi, 29 août 2012 16.01:43, Jon Dowland a écrit :
> 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? Fo
On Wed, Aug 29, 2012 at 03:17:15PM +0100, Dmitrijs Ledkovs wrote:
> I don't think it's worth +dfsg, and CPU cycles will only be wasted once
> on the maintainer side, since most of PNGs are in arch:all packages anyway.
I used to hack on the games-thumbnails package a bit, which ran optipng as part
On Wed, 29 Aug 2012 13:47:00 +0200, Vincent Lefevre wrote:
> > > There's also usbnet, which is used when I connect my Nokia N900 to
> > > my laptop. There must also be a fixed setup, but I haven't found a
> > > solution to recognize my N900 with ifupdown (the MAC address changes
> > > too often).
sorry for the noise.. wrong list due to address auto-completion failure.
--
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/503e2131.6020...@netstyle.ch
On 29/08/12 15:01, Jon Dowland wrote:
> 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 -o
On Tue, Aug 28, 2012 at 17:18:48 +0200, Sylvestre Ledru wrote:
> 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 h
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
folgende aenderungen werden in kuerze deployed..
commit e8a6bbdf2efc0ed75058f53e72d8f202f3f0ac27
Author: Daniel Baumann
Date: Wed Aug 29 14:00:38 2012 +0200
Removing hazardous alias of 'ls -la' on '.', this is dangerous,
don't do such things.
commit f715801507bbc2781b771dd732636aaa1222
On Wed, Aug 29, 2012 at 09:19:17AM +0800, Paul Wise wrote:
> 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
Package: wnpp
Severity: wishlist
Owner: "Gonéri Le Bouder"
* Package name: fusioninventory-agent-task-network
Version : 1.0.1
Upstream Author : fusioninventory-de...@lists.alioth.debian.org
* URL : http://www.fusioninventory.org/
* License : GPL-2+
Programmin
On Aug 29, Guillem Jover wrote:
> I thought this was already the consensus, and the only dissenting
> opinion was that the base system should still be using gzip so that
> foreign non-Debian systems can unpack it w/o requiring to build or
> install xz beforehand.
I am not sure if there was a cons
On 08/19/2012 07:30 PM, Russ Allbery wrote:
> Marc Haber writes:
>
>> Amen. I find it derogatory towards the people spending months of their
>> private time to make exotic ports work to call their work "toy ports".
>> I am seriously thinking about a GR explicitly endorsing the work on more
>> exo
On 08/28/2012 06:05 PM, Don Armstrong wrote:
> 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 s
On 2012-08-29 19:17:36 +0800, Paul Wise wrote:
> On Wed, Aug 29, 2012 at 5:46 PM, Vincent Lefevre wrote:
> > There's also usbnet, which is used when I connect my Nokia N900 to
> > my laptop. There must also be a fixed setup, but I haven't found a
> > solution to recognize my N900 with ifupdown (the
On Wed, Aug 29, 2012 at 5:46 PM, Vincent Lefevre wrote:
> There's also usbnet, which is used when I connect my Nokia N900 to
> my laptop. There must also be a fixed setup, but I haven't found a
> solution to recognize my N900 with ifupdown (the MAC address changes
> too often).
I'm using the NM s
On Wed, Aug 29, 2012 at 09:17:19AM +0100, Simon McVittie wrote:
> On 29/08/12 07:55, Andreas Tille wrote:
> > 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
On 2012-08-28 22:41:38 +0300, Serge wrote:
> 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-
Chris,
your text is very hard to read and parse.
Could you assemble your comments into consistent paragraphs of
suggested texts? (E.g. the final versions of the text you suggest we
use. Or send a patch.)
O.
On Wed, Aug 29, 2012 at 10:32 AM, Christoph Anton Mitterer
wrote:
> On Wed, 2012-08-29
* Simon McVittie , 2012-08-29, 09:17:
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).
This is a security flaw if you want uscan to be safe to use on
untrusted source (e.g. in DEHS). It seems that uscan tri
Le 29 août 2012 10:17, "Simon McVittie" a écrit :
>
> On 29/08/12 07:55, Andreas Tille wrote:
> > 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
> > source
Simon McVittie writes:
> Unfortunately, this isn't fully compatible with what Autoconf does (see
> "info autoconf 'Fortran Compiler Characteristics'"). Autoconf
> distinguishes between F77 and "modern Fortran" (whatever that means),
> and cmake seems to have taken one variable name from each set.
Vincent Danjean writes:
> 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
Le 29 août 2012 10:23, "Sylvestre Ledru" a écrit :
>
> Le 29/08/2012 10:00, Simon McVittie a écrit :
>
>> On 28/08/12 16:54, Mathieu Malaterre wrote:
>>>
>>> On Tue, Aug 28, 2012 at 5:53 PM, Mathieu Malaterre
wrote:
At least from cmake point of view, a user need to provide an env var
>>
On Wed, 2012-08-29 at 09:28 +0200, Ondřej Surý wrote:
> With much cooler head and weekend after me and after carefull
> consideration of Chris's
> comments I have decided to go with:
Good =)
Some comments to your text :)
> php5 (5.4.4-7) unstable; urgency=low
>
> * As a side effect of MIME-Typ
On 29/08/12 09:22, Sylvestre Ledru wrote:
> Le 29/08/2012 10:00, Simon McVittie a écrit :
>> Autoconf 2.69 in sid documents support for:
>> [some languages]
>
> Great list. You constructed yourself or it is part of the autoconf
> documentation ?
Both. :-) It's my summary of what's in "info autocon
Le 29/08/2012 10:00, Simon McVittie a écrit :
On 28/08/12 16:54, Mathieu Malaterre wrote:
On Tue, Aug 28, 2012 at 5:53 PM, Mathieu Malaterre wrote:
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
On 29/08/12 07:55, Andreas Tille wrote:
> 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
>
On 28/08/12 16:54, Mathieu Malaterre wrote:
> On Tue, Aug 28, 2012 at 5:53 PM, Mathieu Malaterre wrote:
>> 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'
Unfortunately, this isn'
Hi!
On Tue, 2012-08-28 at 12:10:18 +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 Wed, Aug 29, 2012 at 2:29 AM, Charles Plessy wrote:
> 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
63 matches
Mail list logo
