Tomas Pospisek writes:
> On Mon, 18 Jun 2012 14:10:46 +0100, Ben Hutchings
> wrote:
>> On Mon, 2012-06-18 at 20:40 +0800, Paul Wise wrote:
>>> On Mon, Jun 18, 2012 at 5:40 PM, Tomas Pospisek wrote:
>>>
>>> > I want to announce restart-services here [1][2]. It's a script
>>> > that tries to rest
Joachim Breitner writes:
> Hi,
>
> Am Donnerstag, den 14.06.2012, 11:10 +0200 schrieb Bernd Zeimetz:
>> > The only problem I see with this is that if the build dependencies can
>> > only be calculated after a full build, building source and binaries
>> > requires two builds (and a third one if de
Ben Hutchings writes:
> On Tue, 2012-06-12 at 17:45 +0200, David Kalnischkies wrote:
>> On Mon, Jun 11, 2012 at 9:40 PM, Michael Gilbert wrote:
>> > In particular, I filed a bug against dpkg requesting that it produce
>> > more informative error messages in these cases [0], but I wonder if a
>>
Andreas Barth writes:
> * David Kalnischkies (kalnischk...@gmail.com) [120612 18:03]:
>> You need to upgrade to support MultiArch,
>> but you need MultiArch to upgradeâ¦
>> (beside, how would the detection for such a message look like?)
>
> We had discussed to export foreign-arch packages to the
Guillem Jover writes:
> On Sun, 2012-06-10 at 14:40:28 +0200, Raphael Hertzog wrote:
>> On Sun, 10 Jun 2012, Guillem Jover wrote:
>> > As I mentioned in the long ref-counting thread, I strongly disagree this
>> > is a correct solution, it just seems like a hack to me. Instead I
>> > think we shou
Bjørn Mork writes:
> Petter Reinholdtsen writes:
>
>> [Bjørn Mork]
>>> I'd like to add another one:
>>>
>>> - a tmpfs is always easy to grow without requiring any special
>>> preparations. Just add more swap. The swap could be on different
>>> disks, and could even be files hosted on oth
Wouter Verhelst writes:
> On Fri, Jun 01, 2012 at 07:00:52PM +0300, Serge wrote:
>> 2012/6/1 Goswin von Brederlow wrote:
>> > So tmpfs would basically never be used despite the benefits.
>>
>> Well, nobody named the benefits yet.
>
> - You could mount your
Salvo Tomaselli writes:
>> >But does the default have to be maximised for the dumbest possible user?
>> >Or should the default rather be for the intelligent user doing the right
>> >things?
>>
>> But the intelligent user can change the default hisself, the dumbest
>> canât. And Debian does all
Josselin Mouette writes:
> Le jeudi 07 juin 2012 à 15:48 +0100, Ben Hutchings a écrit :
>> There's no need to be a dick about it.
>
> Because this discussion was all about not being a dick to begin with, of
> course.
>
> Remind me who, in absence of consensus, explained that if tmpfs was
> ena
Simon McVittie writes:
> On 05/06/12 16:52, Joey Hess wrote:
>> This bug is a textbook example of making the perfect the enemy of
>> the good.
>
> Yes, pretty much. On the bright side, multiarch and a modern Wine
> version have both arrived (Wine 1.4 is admittedly only in experimental
> right now
Stephan Seitz writes:
> On Tue, Jun 05, 2012 at 10:33:13AM +0200, Goswin von Brederlow wrote:
>>Personally I thing DVD ISO images (downloaded) belong in your $HOME
>
> Donât you think this is getting quite ridiculous? Big temporary
> files belong in your $HOME, but small
Scott Howard writes:
> Hello,
>
> I have a non-free package that is distributable but comes precompiled
> for i386. Squeeze (and previous) released an amd64 package that
> depended on ia32-libs. For wheezy we've been able to use multiarched
> libraries to drop the dependency. Is there a mechanism
Ole Wolf writes:
> 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 > ${m
Stephan Seitz writes:
> 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 thi
Serge writes:
> 2012/6/1 Goswin von Brederlow wrote:
>
>> All the complaints about /tmp as tmpfs come down to one simple issue:
>> The size of the tmpfs isn't chosen well.
>
> Mounting /tmp to tmpfs not just breaks a lot of apps and reduces system
> stability, b
Mike Hommey writes:
> On Tue, Jun 05, 2012 at 09:29:46AM +0300, Serge wrote:
>> 2012/6/1 Goswin von Brederlow wrote:
>>
>> > All the complaints about /tmp as tmpfs come down to one simple issue:
>> > The size of the tmpfs isn't chosen well.
>>
>&g
Uoti Urpala writes:
> 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 i
Salvo Tomaselli writes:
>> 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
Ben Hutchings writes:
> 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 swapp
Salvo Tomaselli writes:
>> 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 e
debian-de...@liska.ath.cx (Olе Streicher) writes:
> 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 leav
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.
>
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
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
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
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 simil
Ben Hutchings writes:
> Most new PCs have an Intel or AMD 64-bit processor, and
> popcon.debian.org shows amd64 numbers almost matching i386.
>
> For some time we have also provided the amd64 kernel for i386, identical
> in all but the package metadata. This has not always been perfectly
> compa
debian-de...@liska.ath.cx (Olе Streicher) writes:
> Goswin von Brederlow writes:
>> debian-de...@liska.ath.cx (Olõ Streicher) writes:
>>> James McCoy writes:
>>>> On Wed, May 16, 2012 at 04:23:05PM +0200, Olõ Streicher wrote:
>>>>> Unpatchi
Thibaut Paumard writes:
> Hi,
>
> Le 18/05/12 13:46, Goswin von Brederlow a écrit :
>>> This works only for the special case that "build" does not change any
>>> source file. Otherwise you would also commit the changed source files.
>>
>> A
Neil Williams writes:
> On Fri, 18 May 2012 14:34:40 +0100
> "Manuel A. Fernandez Montecelo" wrote:
>
>> Hi,
>>
>> 2012/5/18 Daniel Leidert :
>> > Hi,
>> >
>> > Our bug tracker contains items for packages, which do (not longer) exist.
>> > What should happen to them? I see, that it might be a
Adam Borowski writes:
> On Wed, May 16, 2012 at 07:45:24PM -0700, Russ Allbery wrote:
>> Charles Plessy writes:
>>
>> > Also, it is very sad that, as a project, we can not decide whether we go
>> > for 3.0 (git) or not, or have a concrete list of resolvable objections
>> > from the people whose
Adam Borowski writes:
> On Fri, May 18, 2012 at 09:24:04AM +0200, Bernd Zeimetz wrote:
>> On 05/17/2012 04:52 PM, Gergely Nagy wrote:
>> >> I'm confused concerning the above; the point of a VCS in this context is
>> >> to
>> >> track changes to the source package, and the patches are themselves
Julian Andres Klode writes:
> On Fri, May 18, 2012 at 04:06:23PM +0200, Michal Suchanek wrote:
>> FWIW
>>
>> posted on the wiki: http://wiki.debian.org/RepositoryFormat
>>
>> Thanks
>>
>> Michal
>
> I have now documented the Contents indices and the diffs
> as well, mostly (sans the exact form
"Daniel Leidert" writes:
> Hi,
>
> Our bug tracker contains items for packages, which do (not longer) exist.
> What should happen to them? I see, that it might be a good idea to keep them
> for the case, a package is re-introduced. But this might happen only for a
> few packages. Most of them
Roger Leigh writes:
> On Wed, May 16, 2012 at 02:38:14PM +0200, Goswin von Brederlow wrote:
>> That just leaves the question of wether dpkg uses uid/gid or symbolic
>> names when unpacking debs.
>
> I think this one is clear: it must be symbolic since the uids/gids
> ar
debian-de...@liska.ath.cx (Olе Streicher) writes:
> James McCoy writes:
>> On Wed, May 16, 2012 at 04:23:05PM +0200, Olе Streicher wrote:
>>> Unpatching the sources *before* the build process was cleaned up makes
>>> no sense to me at all. Could you provide a use case for that?
>> As was descri
Chris Knadle writes:
> On Wednesday, May 16, 2012 06:38:49, Adam Borowski wrote:
>> On Tue, May 15, 2012 at 10:10:28AM +0100, Jon Dowland wrote:
>> > On Tue, May 15, 2012 at 03:17:17PM +0900, Norbert Preining wrote:
>> > > No, I hereby start saying good by to 3.0
>> >
>> > I'm hoping we can revi
Jon Dowland writes:
> On Wed, May 16, 2012 at 12:38:49PM +0200, Adam Borowski wrote:
>> It is true that 3.0 (quilt) does have a great downside, quilt, but it also
>> has a number of upsides. And working around quilt is simple:
>>
>> echo "single-debian-patch" >debian/source/options
>> echo "/.p
Michal Suchanek writes:
> Excerpts from Ian Jackson's message of Thu May 17 14:53:30 +0200 2012:
>> Michal Suchanek writes ("Re: Bug#671503: general: APT repository format is
>> not documented"):
>> > Excerpts from Filipus Klutiero's message of Wed May 16 18:44:21 +0200 2012:
>> > > Could you cl
debian-de...@liska.ath.cx (Olе Streicher) writes:
> Hi,
>
> I just discovered that debuild does not behave as I would expect from
> the maintainer's guide [1]:
>
> | Cleaning the source and rebuilding the package from your user account
> | is as simple as:
> | $ debuild
> [...]
> | You can clea
"Bernhard R. Link" writes:
> * Norbert Preining [120515 01:10]:
>> For these kind of things the expected behaviour is that quilt and
>> dpkg-source behave the same way, and if not, dpkg-source should
>> warn or whatever.
>
> I think the patched debian source format should not depend on what
> qu
Joey Hess writes:
> Adam Borowski wrote:
>> Could you please mention which ones do not? And if so, how are they
>> relevant/are they fixable?
>
> As one of the maintainers of debootstrap, I am perhaps more aware than
> some how broadly it's used. Ok..
>
> They use it on Android (41,600 hits incl
Roger Leigh writes:
> With the above approach, the only hard question is how to set the
> ownership during the package build. fakeroot handles this just fine,
> but it does require the user/group to be present on the build
> system, which will not always be the case. Is there an alternative
> m
Russ Allbery writes:
> Charles Plessy writes:
>
>> in some of my packages, I give the ownership on some directories in /var
>> to www-data without checking that the www-data group exists, but I guess
>> it is acceptable because it is globally allocated by base-passwd.
>
> Right.
>
>> Dpkg will n
Andres Mejia writes:
> On May 3, 2012 10:20 AM, "Andres Mejia" wrote:
>>
>> On May 3, 2012 9:30 AM, "Pino Toscano" wrote:
>> >
>> > Alle giovedì 3 maggio 2012, Andres Mejia ha scritto:
>> > > On Thu, May 3, 2012 at 3:44 AM, Pino Toscano wrote:
>> > > > Package: libav
>> > > > Version: 6:0.8.1-
Aron Xu writes:
> On Mon, Apr 30, 2012 at 22:21, Goswin von Brederlow wrote:
>> Aron Xu writes:
>>
>>> But what if I endianness does matters for those gettext .mo files?
>>> Installing them as libfoo-translations-be and libfoo-translations-le
>>> w
Aron Xu writes:
> But what if I endianness does matters for those gettext .mo files?
> Installing them as libfoo-translations-be and libfoo-translations-le
> will need some change in gettext support of those
> applications/libraries, that is finding mo files in alternative paths,
> and choosing t
Aron Xu writes:
> On Thu, Apr 26, 2012 at 23:21, Osamu Aoki wrote:
>> Hi,
>>
>> On Sun, Apr 22, 2012 at 03:26:21PM +0200, Julien Cristau wrote:
>>> On Thu, Nov 17, 2011 at 20:03:27 +0100, Jakub Wilk wrote:
>>>
>>> > If a package is marked as "Multi-Arch: same", files with the same
>>> > name hav
Stefano Zacchiroli writes:
> On Fri, Apr 27, 2012 at 12:41:58AM +0200, Goswin von Brederlow wrote:
>> The plan for wheezy is that ia32-libs goes away. At least that it will
>> be just a transitional package that depends on the :i386 packages.
>>
>> And yes, that is
Ian Jackson writes:
> Goswin von Brederlow writes ("Re: Bug#664257: multiarch tuples are not
> documented/defined"):
>> Ian Jackson writes:
>> > What change to the Debian operating system, or to processes,
>> > documents, infrastructure or organisatio
Michael Gilbert writes:
> On Wed, Apr 25, 2012 at 5:27 AM, Goswin von Brederlow
> wrote:
>> Jonas Smedegaard writes:
>>
>>> On 12-04-18 at 07:17pm, Simon McVittie wrote:
>>>> I hesitate to suggest this if there's a possibility that the main win
Jonas Smedegaard writes:
> On 12-04-18 at 07:17pm, Simon McVittie wrote:
>> I hesitate to suggest this if there's a possibility that the main wine
>> package can come up to date before we freeze, but one way to have Wine
>> 1.4 (and/or 1.2) in the distribution without NMUs/hijacks would be a
>
Ian Jackson writes:
> Matthias Klose writes ("Bug#664257: multiarch tuples are not
> documented/defined"):
>> On 18.04.2012 05:16, Jonathan Nieder wrote:
>> > I think the Multiarch/Tuples wiki page is now in a sane state, though
>> > as always it could presumably be improved even more. I think
Raphael Geissert writes:
> Goswin von Brederlow wrote:
>> 3) Aborting the upgrade because dependency boot ordering fails will be a
>> major issue for users. You already mentioned 2 issues and on my system
>> at home I get an error about a dependency loop. Dependency based bo
Petter Reinholdtsen writes:
> [Sven Joachim]
>> I beg to disagree, it is already unsupportable because the only way
>> to test it is to set up a lenny system, create some local init
>> script without LSB headers to prevent migration to dependency based
>> boot, and then upgrade all the way to squ
Roger Leigh writes:
> On Wed, Apr 11, 2012 at 12:13:09PM +0200, Goswin von Brederlow wrote:
>> Roger Leigh writes:
>> As a side note I have a use case at work where static order seems to be
>> needed. We build boot images for network boot of clusters. During boot
>&
Roger Leigh writes:
> Hi,
>
> When dependency-based booting was introduced, it was initially
> entirely optional. We later made it the default, and encouraged
> users to switch to dependency-based boot on upgrade. So today,
> pretty much everyone will be using dependency-based boot with
> there
Gergely Nagy writes:
> "Manuel A. Fernandez Montecelo" writes:
>
>> So I have several related questions:
>>
>> 1) In general, what should the maintainers do to prevent such cases?
>> I guess that one could reassign the bugs from the old package to the
>> new one, but it seems obvious that this c
Josselin Mouette writes:
> Le vendredi 30 mars 2012 à 22:12 +0200, Goswin von Brederlow a écrit :
>> Gnome-desktop, not gnome. Gnome-desktop would depend on base-deskop and
>> gnome and maybe a few more gnome-ish things that aren't in gnome.
>
> Iâd appreciate i
Jon Dowland writes:
> On Fri, Mar 30, 2012 at 02:30:37PM +0200, Goswin von Brederlow wrote:
>> Shouldn't there rather be a base-desktop that both KDE-desktop and
>> GNOME-desktop depend on? A meta package that depends on everything any
>> desktop should have.
>
>
Wookey writes:
> +++ Neil Williams [2012-03-26 09:17 +0100]:
>> Therefore packaging takes no time at all, it is always fully complete
>> before the code itself is even worth evaluating as useful to Debian.
>> The packaging is part of my test harness.
>
> You are only looking at this from the upst
Wookey writes:
> +++ Raphael Hertzog [2012-03-29 21:06 +0200]:
>> Hi,
>>
>> On Thu, 29 Mar 2012, Wookey wrote:
>> > Anyone know when this happened and what if any, the limitations are?
>> > It's certainly true in wheezy, squeeze, precise and oineiric.
>>
>> This has always been the case ever s
Jon Dowland writes:
> On 27/03/12 17:09, Filipus Klutiero wrote:
>> So what do others think?
>
> I think that we need to separate the notion of a debian desktop from
> the GNOME or KDE desktops. Synaptic is probably quite rightly not
> part of either, but I agree that a "default desktop" via ins
Ansgar Burchardt writes:
> Jean-Christophe Dubacq writes:
>> What about a dev. script that would be run in debian/ and would parse
>> debian/control and send the ITP? I can write that!
Yes please.
> The Perl group already has a script that does this: examples/get-itp
> in git.debian.org:/git/p
Andrei POPESCU writes:
> On Ma, 27 mar 12, 08:36:58, David Banks wrote:
>>
>> In the specific case of mosh, I have posted three RFS messages to
>> debian-mentors since filing the ITP, in addition to the creation of the
>> RFS bug after the sponsorship-requests procedure was announced, so the
>>
"Eugene V. Lyubimkin" writes:
> [ sorry for duplicate, Neil, pressed the wrong button ]
>
> On 2012-03-26 09:17, Neil Williams wrote:
>> On Mon, 26 Mar 2012 09:55:35 +0300
>> "Eugene V. Lyubimkin" wrote:
> [...]
>> > No, it's not nothing, and it's not a pointless bureaucracy. Filing an
>> > ITP
"Eugene V. Lyubimkin" writes:
> I disagree almost completely.
>
> On 2012-03-25 16:00, Joey Hess wrote:
>> But still nothing. ITP is more often than not a pointless bureaucracy.
>
> No, it's not nothing, and it's not a pointless bureaucracy. Filing an
> ITP shows your intent to a hundreds of deve
Chris Knadle writes:
> On Sunday, March 25, 2012 19:20:10, Goswin von Brederlow wrote:
>> Joey Hess writes:
> ...
>> > I don't completly boycott filing ITP bugs. I've filed at least three this
>> > decade; two for packages I could not immediatly upload du
Joey Hess writes:
> Christoph Egger wrote:
>> Christoph Egger writes:
>> > Read Policy 5.1 again
>>
>> Well right, that's devref, clicked on the wrong link but still
>
> But still nothing. ITP is more often than not a pointless bureaucracy.
> The turnaround time for packaging the average packag
Ben Hutchings writes:
> On Sat, 2012-03-24 at 14:56 +0100, Goswin von Brederlow wrote:
> [...]
>> FYI: Since I have recieved no objections from ftp-master nor the release
>> team the plan for ia32-libs now looks as follows:
>>
>> Ia32-libs becomes a transitional
Sven Joachim writes:
> On 2012-03-24 10:50 +0100, Adam Borowski wrote:
>
>> On Sat, Mar 24, 2012 at 09:48:58AM +0100, Sven Joachim wrote:
>>> On 2012-03-24 04:04 +0100, Jay Berkenbilt wrote:
>>> > One issue not covered is what to do if your package already builds
>>> > 32-bit libraries on a 64-bi
jida...@jidanni.org writes:
> It doesn't matter who is to blame.
> A simple /etc/init.d/... start test could catch such grave bugs before
> they hit the user.
> Who is to blame could be figured out internally.
And ftp-master should run that after every dinstall run for every single
package in the
Matthias Klose writes:
> On 21.03.2012 11:26, Goswin von Brederlow wrote:
>> Matthias Klose writes:
>>
>>> On 19.03.2012 15:34, Jonathan Nieder wrote:
>>>> Goswin von Brederlow wrote:
>>>>
>>>>> Did you read the wiki page?
>>
Simon McVittie writes:
> On 20/03/12 20:11, Ivan Krylov wrote:
>> Sandbox is a library (and helper utility) to run programs in a "sandboxed"
>> environment. This is used as a QA measure to try and prevent applications
>> from
>> modifying files they should not.
>
> Is sandbox secure (in the
Matthias Klose writes:
> On 19.03.2012 15:34, Jonathan Nieder wrote:
>> Goswin von Brederlow wrote:
>>
>>> Did you read the wiki page?
>>
>> Yes. Is the kind of information on which calling convention, basic
>> system library structures, and so on fo
Jonathan Nieder writes:
> Matthias Klose wrote:
>
>> While we strive to get multiarch ready for squeeze, there is
>> currently nothing to point to what the multiarch tuples actually
>> mean, neither on the Debian side nor on some kind of standards side
>> like the FHS or LSB. This has to be docu
Russ Allbery writes:
> Goswin von Brederlow writes:
>> Vincent Bernat writes:
>>> Goswin von Brederlow writes:
>
>>>> That would actually make things more difficult since then you have to
>>>> add some delay into the sysvinit files to wait for the
Vincent Bernat writes:
> OoO Pendant le repas du dimanche 11 mars 2012, vers 19:24, Goswin von
> Brederlow disait :
>
>>> Yes, but systemd relies on cgroups which are not portable. If all
>>> daemons were able to not fork, it would be easier to conve
Vincent Bernat writes:
> OoO Vers la fin de l'après-midi du dimanche 11 mars 2012, vers 16:14,
> Fernando Lemos disait :
>
>>> Maybe we could  have an intermediate goal to patch any  daemon to add an
>>> option  to not  fork on  start.  If  any daemon  can be  started
>>> without
Davide Prina writes:
> Hi Ian,
>
> On 21/02/2012 15:30, Ian Jackson wrote:
>
>> I support the dak change to split off the long descriptions into their
>> own files.
>
> Packages (P) and Translation-en (T) have some differences, I don't
> understand that there are correct:
> * some packages are in
Oleg writes:
> Hello, list.
>
> I have /var on a separate partition. My /var/run and /var/lock mount as tmpfs:
>
> ~$ grep RAM /etc/default/rcS
> RAMRUN=yes
> RAMLOCK=yes
>
> When i reboot or poweroff my machine i see that unmounting of /var fail
> because
> it busy. If i include lines:
>
> umo
Michael Biebl writes:
> Am 07.03.2012 23:34, schrieb Michael Biebl:
>> On 07.03.2012 22:46, Steve Langasek wrote:
>>> On Wed, Mar 07, 2012 at 10:24:39AM +0100, Michael Biebl wrote:
>>>
It's rather easy to confuse upstart's process tracking. You
explicitly have to tell upstart if a daemo
Michael Biebl writes:
> On 07.03.2012 00:21, Fernando Lemos wrote:
>> Hi,
>>
>> On Tue, Mar 6, 2012 at 7:46 PM, Josh Triplett wrote:
>>> To give one particular example: systemd uses Linux-specific features to
>>> accurately track all the processes started by a service, which allows
>>> accurate
Raphael Hertzog writes:
> Hi,
>
> On Wed, 07 Mar 2012, Thomas Goirand wrote:
>> I've just seen an (ugly) instance of many quilt patches in
>> debian/patches that are patching things inside the debian/ folder. I am
>> wondering if it would be wise to forbid this entirely, and write about
>> it in
Package: wnpp
Severity: wishlist
Owner: Goswin von Brederlow
Package name: libaio-ocaml
Version : 1.0~rc3
Upstream Author : Goswin von Brederlow
URL : http://forge.ocamlcore.org/projects/libaio-ocaml/
Vcs-Git :
git://anonscm.debian.org/pkg-ocaml-maint/packages
Guillem Jover writes:
> On Wed, 2012-02-15 at 16:32:38 -0800, Russ Allbery wrote:
>> Guillem Jover writes:
>> > If packages have to be split anyway to cope with the other cases, then
>> > the number of new packages which might not be needed otherwise will be
>> > even smaller than the predicted
m...@linux.it (Marco d'Itri) writes:
> On Mar 01, Russ Allbery wrote:
>
>> The situation with refcounting seems much less fragile than the situation
>> without refcounting to me.
> I totally agree.
>
> Also, why does refcounting have to be "perfect"?
> What would break if it did not actually chec
Marco d'Itri writes:
> On Feb 29, Russell Coker wrote:
>
>> One thing that would be really convenient in such situations is the ability
>> to
>> have the old and new versions of the package installed such that the new
>> version would run the old version if appropriate.
> Yes. Except that thi
Darren Salt writes:
> I demand that Steve Langasek may or may not have written...
>
> [snip]
>> One of the worst contributors to the use of 'script' in upstart jobs
>> instead of 'exec' is the need for backwards-compatibility with pre-upstart
>> /etc/default/* files. The options here are all fai
Ben Hutchings writes:
> On Tue, Feb 28, 2012 at 09:58:01PM +0100, Goswin von Brederlow wrote:
>> Ben Hutchings writes:
>>
>> > On Tue, Feb 28, 2012 at 04:51:18PM +, Roger Leigh wrote:
>> >> On Sat, Feb 25, 2012 at 12:17:43AM +0200, Uoti Urpala wrote:
>
101 - 200 of 2310 matches
Mail list logo
