Hi all,
thanks to all those who replied to my search quest.
I got hold of Winnie as well and things are in flow.
Mike
--
DAS-NETZWERKTEAM
mike gabriel, dorfstr. 27, 24245 barmissen
fon: +49 (4302) 281418, fax: +49 (4302) 281419
GnuPG Key ID 0xB588399B
mail: mike.gabr...@das-netzwerkteam.de,
On 06/02/2012 04:43 AM, Holger Levsen wrote:
> now that I notice the subject change I also notice the original subject...
>
> hi Thomas 8-)
>
LOL !
I'm amazed that it's seems I'm capable of creating huge uncontrollable
threads out of nowhere (eg: this isn't the first time).
I swear its never i
Hi Mike,
I have been trying to get hold of Patrick too, and succeeded in getting
hold of him ~ 1 day ago. He's still active, just very busy. I hope to
get a longer chat with him over the coming days with respect to lmms
specifically, but I'll mention this discussion too.
--
Regards,
Miah
On June 1, 2012 10:00:52 AM Serge wrote:
...
> I considered that. I was just trying to keep description shorter and
> easier to understand. A more complete description would look like:
> 0. fstab is already processed and /tmp was (or was not) mounted to a
>separate partition.
> 1. init-script c
On Fri, Jun 01, 2012 at 11:19:40PM +0200, Carlos Alberto Lopez Perez wrote:
> On 01/06/12 13:33, Goswin von Brederlow wrote:
> >> > I don't know the ultimate reason behind this ugly behaviour of Linux
> >> > when the swapping process is happening, but I know this is real and it
> >> > happens becau
Steve Langasek wrote:
> On Thu, May 31, 2012 at 06:15:47PM +0200, Bernd Zeimetz wrote:
> > Especially do I fail to understand why a member of the TC, who took part
> > in such discussions before
> > (https://lists.debian.org/debian-devel/2006/05/msg00457.html to name an
> > example), and encouraged
Package: wnpp
Severity: wishlist
Owner: Vincent Danjean
[ opencl-headers maintainers, please read until the end of this ITP ]
* Package name: ocl-icd
Version : 1.0 beta2
Upstream Author : Brice Videau
* URL : http://forge.imag.fr/projects/ocl-icd/
* License
On Fri, 01 Jun 2012 23:37:16 +0200, Ole Wolf wrote:
> > PACKAGE = $(shell dh_listpackages)
> > TMP = $(CURDIR)/debian/$(PACKAGE)
> > Using this method, you can substitute $(PACKAGE) for the package name,
> > which may make your rules file a little prettier...
> Thanks! It turns out I wasn't en
On Fri, May 25, 2012 at 02:22:24AM +0300, Serge wrote:
> Q: /tmp on tmpfs increases apps performance.
> A: What apps? Real apps don't write files during performance-critical
>operations. Even if they do, they write large files. And large files are
>written faster when they're written on rea
Jonathan,
fre, 01 06 2012 kl. 15:36 -0400, skrev Jonathan Yu:
> This may only be a partial help for you (you will still need to
> specify the /usr/... etc stuff), but this is the method we use in the
> Debian Perl group to build the path:
> PACKAGE = $(shell dh_listpackages)
> TMP = $(CURDIR)/
On 01/06/12 13:33, Goswin von Brederlow wrote:
>> > I don't know the ultimate reason behind this ugly behaviour of Linux
>> > when the swapping process is happening, but I know this is real and it
>> > happens because I have experimented this situation myself more than a
>> > couple of times.
> It'
On 01.06.2012 21:49, Tollef Fog Heen wrote:
> ]] Jonas Smedegaard
>
> Hiya,
>
>> I am genuinely interested in understanding the reasons for labeling
>> sponsoree rather than sponsor as maintainer. Could you (or anyone)
>> elaborate on that?
>
> If I'm sponsoring a package, it means I've chec
On Friday 01 June 2012 20:08:22 Jonas Smedegaard wrote:
> On 12-06-01 at 06:06pm, George Danchev wrote:
> > On Thursday 31 May 2012 16:54:13 Scott Kitterman wrote:
> >
> > Hi,
Hi,
> > > > ...hence the Sponsors (who are also a full-fledged DDs) are
> > > > responsible. It is that simple.
> > >
>
On 01.06.2012 19:22, Aaron Toponce wrote:
> By default in Debian, when a service package is installed, such as
> openssh-server, or isc-dhcp-server, it starts the service. This seems
> counter-intuitive to me. I would think that the standard mode of practice
> for installing and running a service w
now that I notice the subject change I also notice the original subject...
hi Thomas 8-)
--
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/201206012243.38011.hol...@lay
On 06/01/2012 05:19 PM, Russ Allbery wrote:
> I don't know if this is all explicitly written down anywhere, but it's
> certainly my feel of the general consensus and social expectations of the
> people who discuss this sort of thing on debian-mentors.
>
I don't know if what you pretend is writt
On Thu, May 31, 2012 at 06:15:47PM +0200, Bernd Zeimetz wrote:
> Especially do I fail to understand why a member of the TC, who took part
> in such discussions before
> (https://lists.debian.org/debian-devel/2006/05/msg00457.html to name an
> example), and encouraged people to do so (that is how I
On Fri, Jun 1, 2012 at 4:22 PM, Holger Levsen wrote:
> Hi,
>
> On Freitag, 1. Juni 2012, Steve Langasek wrote:
> [...]
>> This is very different from what some people mean when they use the word
>> hijack. In part, I think we have a terminological problem here; I don't
>> know if it's a matter of
Hi,
On Freitag, 1. Juni 2012, Steve Langasek wrote:
[...]
> This is very different from what some people mean when they use the word
> hijack. In part, I think we have a terminological problem here; I don't
> know if it's a matter of non-native speakers using the word differently,
> but the word
Hi Tollef,
On 12-06-01 at 09:55pm, Tollef Fog Heen wrote:
> ]] Jonas Smedegaard
>
> > Hi Aaron,
> >
> > On 12-06-01 at 11:22am, Aaron Toponce wrote:
> > > Just because I have installed a service package, doesn't mean I
> > > want the service immediately running after installation. I would
> >
On Freitag, 1. Juni 2012, Aaron Toponce wrote:
> I'm trying to dig through the archives to see if this has been discussed,
#661496 and friends.
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive
]] Jonas Smedegaard
> Hi Aaron,
>
> On 12-06-01 at 11:22am, Aaron Toponce wrote:
> > Just because I have installed a service package, doesn't mean I want
> > the service immediately running after installation. I would like to
> > spend the necessary time as an administrator to configure and se
]] Jonas Smedegaard
Hiya,
> I am genuinely interested in understanding the reasons for labeling
> sponsoree rather than sponsor as maintainer. Could you (or anyone)
> elaborate on that?
If I'm sponsoring a package, it means I've checked that its quality is
good enough that I consider it a wo
Hi,
On Fri, Jun 1, 2012 at 12:33 PM, Ole Wolf wrote:
> However, I don't know how to specify the target path for the man pages,
> which I've tentatively indicated by ${mandir} in the above snippet. I'm
> not using autoconf, which seems to set some path variables.
>
This may only be a partial hel
On Thu, May 31, 2012 at 08:20:40AM +0200, Raphael Hertzog wrote:
> On Wed, 30 May 2012, Steve Langasek wrote:
> > There is no excuse for hijacking a package, ever.
> > If the maintainer is MIA, use the MIA process to get the package orphaned.
> This goes too far IMO. One of the reasons why the MI
Aaron Toponce writes:
> I'm trying to dig through the archives to see if this has been discussed,
> and I'm only finding random one-off discussions here and there about it.
> Nothing concrete. If it has already been discussed in great detail, my
> apologies.
It has -- repeatedly.
This is almost
Hi Aaron,
On 12-06-01 at 11:22am, Aaron Toponce wrote:
> Just because I have installed a service package, doesn't mean I want
> the service immediately running after installation. I would like to
> spend the necessary time as an administrator to configure and secure
> the service to my liking,
On 12-06-01 at 06:06pm, George Danchev wrote:
> On Thursday 31 May 2012 16:54:13 Scott Kitterman wrote:
>
> Hi,
>
> > > ...hence the Sponsors (who are also a full-fledged DDs) are
> > > responsible. It is that simple.
> >
> > If it's really that simple, one should never sponsor a package one
>
Goswin von Brederlow wrote:
> > Le vendredi 25 mai 2012 à 16:01 +0300, Uoti Urpala a écrit :
> >> There is one significant difference though. When you read data back to
> >> memory from swap, the kernel does not remember that it already exists on
> >> disk; when the data is evicted from memory a
On 12-06-01 at 11:21am, Petter Reinholdtsen wrote:
>
> [Jonas Smedegaard]
> > Is my point clear now (even if is may disagree with my reasoning)?
>
> I find your point quite clear, but suspect you misunderstood those
> claiming the sponsor have responsibilities regarding package
> maintenance.
>
I'm trying to dig through the archives to see if this has been discussed,
and I'm only finding random one-off discussions here and there about it.
Nothing concrete. If it has already been discussed in great detail, my
apologies.
By default in Debian, when a service package is installed, such as
op
On Fri, Jun 01, 2012 at 02:19:53PM +0200, Goswin von Brederlow wrote:
In general your option assumes that you need the maximum amount of free
space in /tmp. That is simply not true. In most cases a small /tmp is
just peachy. Because of this it is hard to set a minimum size where
tmpfs would be to
I am building a package where I'm overriding the man page generation to
include man pages that are generated at build time. A simplified version
of the override in my debian/rules is:
override_dh_installman:
dh_installman --
/somepath/create-a-man-page > ${mandir}/man1/packagename.1
Howev
On Thursday 31 May 2012 16:54:13 Scott Kitterman wrote:
Hi,
> > ...hence the Sponsors (who are also a full-fledged DDs) are responsible.
> > It is that simple.
>
> If it's really that simple, one should never sponsor a package one doesn't
> care to maintain. If this is the case, we should just
2012/6/1 Goswin von Brederlow wrote:
> That should be:
> mount /tmp to tmpfs only when amount of free space in /tmp is fewer
> than the tmpfs would have or when /tmp is currently read-only.
Yes, of course. IIRC current script already checks for read-only root.
So this check don't have to be add
On Tue, Jul 26, 2011 at 6:03 PM, Paul Wise wrote:
> On a related note, an "OEM" mode for d-i is something I believe we
> currently lack. Requirements for this would be the above "unconfigured
> systems" idea plus some on-boot UI to configure the system (timezone,
> users, etc).
The Mint folks ha
On 01/06/12 14:53, Ben Hutchings wrote:
On Fri, 2012-06-01 at 14:10 +0100, Philip Ashmore wrote:
On 30/05/12 22:42, Karl Goetz wrote:
> On Wed, 30 May 2012 13:20:24 +0100
> Philip Ashmore wrote:
> Could you give examples of things lacking permalinks?
> thanks,
> kk
>
http
2012/6/1 Roger Leigh wrote:
> I'm certainly not averse to switching the default back, if this is the
> best solution at the present time for the majority of our users.
If only it was the best solution...
> As was seen in both this an earlier discussions, there is not a clear-cut
> consensus here
> And you are not correct here. The tmpfs defaults to guaranteeing
> a certain fixed size being available, as I stated above. If the
> memory was used up by applications and data, then the system will
> swap, drop cached data, flush unwritten data to disc etc. in order
> to make room for it. Yo
On Fri, 2012-06-01 at 14:10 +0100, Philip Ashmore wrote:
> On 30/05/12 22:42, Karl Goetz wrote:
> > On Wed, 30 May 2012 13:20:24 +0100
> > Philip Ashmore wrote:
> >
> >> On 30/05/12 12:29, Bernd Zeimetz wrote:
> >>> On 05/26/2012 09:09 PM, Philip Ashmore wrote:
> On 05/26/2012 06:53 A
> No, tmpfs will be swapped out if you don't use a file for a while but
> something else uses memory, including IO caching.
unless too many things want to use memory, then tmpfs gives a great
contribution in taking down the machine.
As you pointed out yourself in another email, under memory pr
Package: wnpp
Severity: wishlist
Owner: bilibop project
* Package name: bilibop
Version : 0.1
Upstream Author : bilibop project
* URL : https://poivron.org/~quidame/bilibop_project/
* License : GPL-3.0+
Programming Lang: Shell
Description : run Debian
> If anyone wants to experience that then write out some GB of data over
> NFS. After a short while processes will hang while others keep running.
True, that's what i was saying.
But if there is not enough memory, it's not only one process that will hang.
It's everything.
So i think that adding p
On 30/05/12 22:42, Karl Goetz wrote:
> On Wed, 30 May 2012 13:20:24 +0100
> Philip Ashmore wrote:
>
>> On 30/05/12 12:29, Bernd Zeimetz wrote:
>>> On 05/26/2012 09:09 PM, Philip Ashmore wrote:
On 05/26/2012 06:53 AM, Jonathan Callen wrote:
> On 05/25/2012 10:03 PM, Philip Ashmore wrot
On Fri, May 25, 2012 at 12:44:03PM +0100, Roger Leigh wrote:
> On Fri, May 25, 2012 at 02:22:24AM +0300, Serge wrote:
> > I've read across different debates about whether using tmpfs is good or bad
> > but I could not find the most important reason, so here it is...
>
> I haven't got anything part
On Mon, May 28, 2012 at 01:21:43PM +0800, Thomas Goirand wrote:
> On 05/28/2012 05:32 AM, Roger Leigh wrote:
> > On Sun, May 27, 2012 at 10:46:27PM +0800, Thomas Goirand wrote:
> >> On 05/25/2012 07:44 PM, Roger Leigh wrote:
> >>> However, the majority of
> >>> software which finds the tmpfs too sm
On Fri, 2012-06-01 at 11:59 +0200, Goswin von Brederlow wrote:
> Ben Hutchings writes:
>
> > On Sun, 2012-05-20 at 11:27 +0200, Goswin von Brederlow wrote:
> >> Ben Hutchings writes:
> >> > Eventually (wheezy+2? +3?) we would stop building a kernel package for
> >> > i386.
> >>
> >> As in drop
Serge writes:
> 2012/5/28 Roger Leigh wrote:
>
>> The primary cause of problems is simply that the tmpfs /tmp isn't big
>> enough. [...] what guarantees are offered by the system in terms of
>> minimum and maximum available space on /tmp? [...] Consider the default:
>> /tmp is on the rootfs (whic
Serge writes:
> I'm asking for *popular* apps, that create files in /tmp, *never put
> large files* there, and become *noticeably* faster with /tmp on tmpfs?
gcc, ocamlopt, mc, lintian
MfG
Goswin
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsu
Josselin Mouette writes:
> Le vendredi 25 mai 2012 à 16:01 +0300, Uoti Urpala a écrit :
>> There is one significant difference though. When you read data back to
>> memory from swap, the kernel does not remember that it already exists on
>> disk; when the data is evicted from memory again, it
Salvo Tomaselli writes:
>> So what? If you write to a normal file system, it goes into the page
>> cache, which is pretty much the same as writing into tmpfs.
> tmpfs will make it stay forever in the RAM, caches are flushed to disk and
> their space can be used for new things.
>
Hi,
On Thu, May 31, 2012 at 10:56:50PM +0200, Michael Biebl wrote:
> On 31.05.2012 21:35, Andreas Tille wrote:
>
> > In any case the idea is to collect issues of broken mime support where
> > maintainers are unable / not willing to respect Debian policy 9.7.
> > Adding more entries is simple: Ju
Carlos Alberto Lopez Perez writes:
> On 25/05/12 12:20, Henrique de Moraes Holschuh wrote:
>> On Fri, 25 May 2012, Salvo Tomaselli wrote:
Because paging out a couple Gigabytes is veery different from
writing a couple Gigabytes to disk, of course.
>>>
>>> Yes because writing that on
Salvo Tomaselli writes:
>> Because paging out a couple Gigabytes is veery different from
>> writing a couple Gigabytes to disk, of course.
>
> Yes because writing that on disk will only block the thread performing the
> write, not every thread that tries to allocate memory.
Wrong. The threa
Goswin von Brederlow writes:
> debian-de...@liska.ath.cx (Ole Streicher) writes:
>> I think the best way would be that debuild/dpkg-buildpackage would not
>> automatically unapply the patches (so it would leave the source in the
> It doesn't automatically unapply the patches. It only restores the
Vincent Danjean writes:
> Le 25/05/2012 05:03, Russell Coker a écrit :
>> On Fri, 25 May 2012, Serge wrote:
>>> Q: /tmp on tmpfs increases apps performance.
>>> A: What apps? Real apps don't write files during performance-critical
>>>operations. Even if they do, they write large files. And
Nikolaus Rath writes:
> Thomas Goirand writes:
>> On 05/25/2012 05:33 PM, Mehdi Dogguy wrote:
What if we're installing Debian on a very small system, and that we
need operations with big files in /tmp?
>>>
>>> Increase your swap?
>>
>> So, in this case, we will have the following
Carlos Alberto Lopez Perez writes:
> On 25/05/12 12:14, Henrique de Moraes Holschuh wrote:
>> On Fri, 25 May 2012, Thomas Goirand wrote:
>>> for small files, and in that case, it's faster. In reality, it's
>>> not that much faster, thanks to Linux caching of the filesystem,
>>
>> Under heavy fil
Henrique de Moraes Holschuh writes:
> On Fri, 25 May 2012, Thomas Goirand wrote:
>> for small files, and in that case, it's faster. In reality, it's
>> not that much faster, thanks to Linux caching of the filesystem,
>
> Under heavy filesystem IO load, yes it is. By several orders of magnitude.
Thorsten Glaser writes:
> Just curiousâ¦
>
> I thought one is supposed to use Multi-Arch now, and that
> biarch/triarch can finally go away.
>
> Seeing the trouble broonie has with zlib, why are those
> packages still built anyway? Canât they please go away?
>
> bye,
> //mirabilos
gcc still,
debian-de...@liska.ath.cx (Olе Streicher) writes:
> Goswin von Brederlow writes:
If you need to change a file then that means that file isn't source
anymore but generated. Try switching to out-of-tree builds if you have
something like that.
>>>
>>> What is the advantage of that? F
m...@linux.it (Marco d'Itri) writes:
> On May 18, Russ Allbery wrote:
>
>> I do this work in cases where keeping the patches separate is useful for
>> some reason, but mostly it's not.
> Some of my packages have 30-60 patches ("mature" software...), and
> merging them would make them impossibile
Ben Hutchings writes:
> On Sun, 2012-05-20 at 11:27 +0200, Goswin von Brederlow wrote:
>> Ben Hutchings writes:
>> > Eventually (wheezy+2? +3?) we would stop building a kernel package for
>> > i386.
>>
>> As in drop the i386 arch?
>
> No, keep i386 userland only. Though we might consider reduc
Guillem Jover writes:
> On Sun, 2012-05-20 at 14:03:35 +0200, David Kalnischkies wrote:
>> On Sun, May 20, 2012 at 1:10 PM, Sven Joachim wrote:
>> > On 2012-05-20 11:27 +0200, Goswin von Brederlow wrote:
>> > > Slightly OT but I wanted to mention it for its similarity:
>> > >
>> > > One thing th
[Jonas Smedegaard]
> Is my point clear now (even if is may disagree with my reasoning)?
I find your point quite clear, but suspect you misunderstood those
claiming the sponsor have responsibilities regarding package
maintenance.
To me it is obvious that the sponsor is also responsible for a
pack
Jonas Smedegaard writes:
> My point is that either we are all wasting our time declaring a
> meaningless "Maintainer:" control field, or Bernd is wrong and the
> uploader responsibility is for the contents of the upload - which
> includes stating who is then to be held responsible for the
> maint
Hi Svante,
On 12-06-01 at 09:16am, Svante Signell wrote:
> Regarding DMs the non-responsiveness of *some* of them is frustrating,
> they don't bother to comment on _any_ of the bug reports. Is that the
> way a DM is supposed to work? And with the recent discussions on
> d-devel about hijacking
On Friday 01 June 2012 09:16:35 Svante Signell wrote:
> Regarding DMs the non-responsiveness of some of them is frustrating,
> they don't bother to comment on any of the bug reports. Is that the
> way a DM is supposed to work?
I don't think so.
> And with the recent discussions on d-devel
> abou
On 12-05-31 at 06:08pm, Holger Levsen wrote:
> On Donnerstag, 31. Mai 2012, Jonas Smedegaard wrote:
> > You still avoid my question: What does "Maintainer:" mean?
>
> why do you ask rhetoric questions? It's defined in policy and you know
> it. So whats the point?
Context of my question is Bernd a
On Thu, 2012-05-31 at 17:40 -0500, Gunnar Wolf wrote:
> Svante Signell dijo [Thu, May 31, 2012 at 11:45:13PM +0200]:
> > > It's *usually* not what you want to do. There are several cases where
> > > different versions of the same program are available in Debian, and I
> > > am unfamiliar with the c
70 matches
Mail list logo
