Re: Packaging a new release of released SW, not considered by the DM?

[Svante Signell]

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 case at hand, but it's usually where a specific
> > > older version of a package is depended upon by large amounts of
> > > software, and changes in new versions are not compatible. They often
> > > bring in maintenance hell issues.

One example is to upload a new release to experimental, not sid! Being
there does not automatically make it progress to sid, tesing and stable
does it?

> > > In this case, you should discuss with the DM about the "whatever
> > > reason" you mention, maybe bring it up here (so it gets wider exposure
> > > and more informed people get to have a say). You can ultimately ask
> > > the Technical Committee, but that's a venue of action very seldom
> > > taken (and I think that even "very seldom" might be an overstatement).

Well the DM is *non-responsive*, what to do?

> > Thank you for your time,
> > 
> > Fortunately, I'm not a hurd porter any longer an whatever you choose to
> > do it is not longer my business. Thank you for your attention
> 
> Huh‽
> 
> Well, the original question I replied to was posted by you... I fail
> to understand your answer. There was no mention of any specific
> program, architecture, kernel or whatever.

Just to clarify, I have been contributing with bug reports and patches
for various packages, etc for a long time. I'm not a DM or DD.

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 etc it seems that if you are a DM for a package is set
in stone *forever*.

I really wonder if Debian is for me at all. There are other free
software distributions, Ubuntu, Redhat Fedora, Mandriva, etc. I've been
contributing there before. And there are even really free software
distributions. So why stick to Debian?



-- 
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/1338534995.5450.136.ca...@hp.my.own.domain

Maintainer responsible for or only doing maintenance?

[Jonas Smedegaard]

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 arguing that responsibility lies at the 
uploader, not only for the contents of the upload but also for its 
future maintenance.

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
maintainance.

In my interpretation, maintainer is expected to act responsibly.

Uploader is expected to act responsibly too: The act of uploading covers 
ensuring the vailidy of statements in the packaging (which is especially 
tricky for sponsoring of work outside our Web of Trust).  The act of 
uploading does *not* IMO cover ongoing maintenance of the package.

But you are right, let's simply look at Policy. I found this at §3.3:

> The maintainer is responsible for maintaining the Debian packaging 
> files, evaluating and responding appropriately to reported bugs, 
> uploading new versions of the package (either directly or through a 
> sponsor), ensuring that the package is placed in the appropriate 
> archive area and included in Debian releases as appropriate for the 
> stability and utility of the package, and requesting removal of the 
> package from the Debian distribution if it is no longer useful or 
> maintainable.

Enrico told me (discretely, possibly assuming it was common knowledge to 
the rest of the community) that "Maintainer:" is often a mailinglist 
which cannot be in our WoT and therefore cannot be held responsible.  
And that therefore the uploader really is the responsible party.

Let's see what is said about "Uploaders:" control field (again §3.3):

> If the maintainer of the package is a team of people with a shared 
> email address, the `Uploaders' control field must be present and must 
> contain at least one human with their personal email address.  See 
> Section 5.6.3, ``Uploaders'' for the syntax of that field.

Hmm. Did you see that? According to Policy, maintainer is responsible - 
even for the tasks done by uploaders - and uploaders are not defined as 
responsible.  I might be missing something, but searching all of Policy 
I found only tools, scripts, authors (of the Policy document) and 
maintainers to be described as responsible.

My point here is not to be nitpicking with Policy and claiming that 
noone but maintainers are responsible - but I do find it quite hard to 
fathom that maintainers are *not* responsible.

Did I miss something?  Did Bernd perhaps simply mean that in *addition* 
to maintainers, uploaders also have a bit of responsibility for some 
things (but not maintenance which is what this thread is about)? Could 
have helped me to understand what Bernd meant if he had simply answered 
my direct question instead of talking around it answering question with 
a counter-question,

Is my point clear now (even if is may disagree with my reasoning)?


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: Digital signature

Re: Packaging a new release of released SW, not considered by the DM?

[Dominique Dumont]

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
> about hijacking etc it seems that if you are a DM for a package is set
> in stone *forever*.

There's a middle ground between hijacking and letting a package rot: Debian 
developers reference provides instructions to deal with "inactive 
and/or unreachable maintainers" [1]. I know from experience that 
following this process is an exercice is patience, but it's the 
best way to deal with maintainers which may be distracted by, well, 
real life events.

> I really wonder if Debian is for me at all. There are other free
> software distributions, Ubuntu, Redhat Fedora, Mandriva, etc. I've been
> contributing there before. And there are even really free software
> distributions. So why stick to Debian?

Heh, I could give you an answer, but it would be valid only for me ;-)

All the best

[1] 
http://www.debian.org/doc/manuals/developers-reference/beyond-pkging.html#mia-qa

-- 
https://github.com/dod38fr/config-model/ -o- http://search.cpan.org/~ddumont/
http://ddumont.wordpress.com/-o-   irc: dod at irc.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/201206011028.22691@debian.org

Re: Packaging a new release of released SW, not considered by the DM?

[Jonas Smedegaard]

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 etc it seems that if you are a DM for a 
> package is set in stone *forever*.

The general rule is that when you are maintainer for a package, you stay 
maintainer.

...but maintainer role is not "forever", though.  But Debian praise 
stability and reliability, and both are generally helped when you are 
not "shopping around" but devote time to and grow detailed knowledge 
about specific pieces over longer time.

...but Debian rules are not set in stone, either¹. Note how I said 
"generally" several times above. What you experience at the mailinglist 
is discussing what is facts *today*, both to hold each other to an 
agreed consensus, and to consider if relevant to change to a different 
(hopefully better) consensus in the future.

Hope that helped you gain interest in Debian :-)


 - Jonas

P.S.

I am not _always_ yelling and nitpicking.  At least that's what Siri (my 
girlfriend), Gunnar Wolf and Andreas Tille tells me...


¹ Ahem. Debian Policy _is_ probably what most would call "set in stone",
but - as I suspect was also partly Andreas Tille's point in his 
once-a-day mail yesterday - we wrote that "law" ourselves, and are free 
to rewrite it.  So soapstone or something... :-)

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: Digital signature

Re: Maintainer responsible for or only doing maintenance?

[Russ Allbery]

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
> maintainance.

> In my interpretation, maintainer is expected to act responsibly.

I think this is too stark, or at least I feel like my personal position on
this is part of an excluded middle.

For the specific case of sponsored packages, for exactly the reasons that
you have argued previously on this thread, we know that the package
maintainer's affiliation with (and often committment to) Debian may not be
as strong as the Debian Developer who is sponsoring the package.
Therefore, in the specific case of sponsored packages, while the package
maintainer is still responsible, we ask the sponsor to exercise some
oversight over that responsibility and be prepared to step in if the
maintainer is not fulfilling that responsibility for whatever reason.

I think we also, at least informally, recognize the sponsor has having
more control over the package than they normally would when they're not
the maintainer, precisely because with repsonsibility should come the
power to exercise that responsibility.

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.

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

Re: Maintainer responsible for or only doing maintenance?

[Petter Reinholdtsen]

[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
package, when the maintainer become unresponsive or missing.  When the
maintainer is active and available, the sponsor do not have to step in
and the responsibility is "sleeping". :)

The maintainer is responsible in the day to day maintenance, but when
I sponsor packages I also keep in mind that I might end up having to
care about the package some time in the future if the listed
maintainer looses interest or disappears for other reasons.

You seem to argue that this should not be the case.  Is this because
of your current sponsor practice, or is there some other experience
behind your view on the responsibilities of a package sponsor in
Debian?
-- 
Happy hacking
Petter Reinholdtsen


-- 
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/2fl62bbmloo@login2.uio.no

Re: amd64 as default architecture

[Goswin von Brederlow]

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 that should be tested and then documented prominently as yay
>> > > or nay in the wheezy upgrade notes is wether one can cross-grade from
>> > > i386 to amd64 using multiarch. Wether one can install apt/dpkg:amd64 and
>> > > then migrate to a 64bit userspace.
>> >
>> > Won't work in wheezy, apt does not support crossgradesน.

Why? What breaks? Any bugs filed yet?

I'm sure you are right that it currently doesn't work out of the box. I
don't agree with killing this for wheezy without having some idea of how
much breakage is involed though. I've seen reports from other people
that have done crossgrades in the past with some handholding so it isn't
impossible.

Testing (see below) shows that there is one big issue, namely that
crossgrading wants to remove the package before installing the new
one. Everything else seems to be minor and package specific issues (like
dash trying to overwrite its diversion). But testing on a minimal chroot
is hardly conclusive so if you know other issues then feel free to speak
up.

>> There is no real reason to require apt to do the heavy lifting here.
>> It would be nice, but it is a one-time action, so a specialized tool wouldn't
>> hurt muscle memory too much. Install essentials and apt and you should
>> be good to go to proceed as usual, just with a different architecture…
>
> I disagree that this is a one-time action, people might want to
> cross-grade specific packages back and forth, not just the entire
> installation. Also unsafe cross-grade does not only affect the
> Essential set, it also affects anything involved in the boot process,
> if for whatever reason the system crashes and apt would have removed
> such package the system would be rendered unbootable.

Crossgrading a single package should already work. That is just normal
multiarch stuff. As long as the dependencies are resolved, which
multiarch does, there should be no problem. All assuming the package
doesn't have architecture specific data that will break (like git-svn).

Except with the essential set you don't always have dependencies. But
I'm not concerned there. You always have depends on libraries through
the shlibs/symbols files and everything else is (or should be)
Multi-Arch: foreign and work in any arch.

>> Even most essentials are easy to crossgrade, the only really difficult one
>> is dpkg and it's dependencies as you have to take care of not breaking it
>> while it crossgrades itself.
>
> I guess I don't see the additional complexity in the dpkg specific
> case, it just needs the shared libraries to be installed which should
> be co-installable anyway, and the rest being M-A:foreign.

The complexity in dpkg (and apt) is the metadata. When crossgrading
apt/dpkg the notion of native and foreign architecture switches and that
impacts /var/lib/dpkg/info/ and the handling of Arch:all packages.

So lets test this:

cdebootstrap -v sid sid http://ftp.debian.org/
# dpkg --add-architecture i386
# apt-get update
# apt-get install apt:i386 dpkg:i386
Reading package lists... Done
Building dependency tree... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 apt:i386 : Depends: debian-archive-keyring:i386 but it is not installable
E: Unable to correct problems, you have held broken packages.

Doh, debian-archive-keyring isn't Multi-Arch: foreign (yet). Lets fix
that and try again:

# apt-get install apt:i386 dpkg:i386
Reading package lists... Done
Building dependency tree... Done
The following extra packages will be installed:
  gcc-4.7-base:i386 libapt-pkg4.12:i386 libbz2-1.0:i386 libc6:i386
  libc6-i686:i386 libgcc1:i386 libselinux1:i386 libstdc++6:i386 zlib1g:i386
Suggested packages:
  aptitude:i386 synaptic:i386 wajig:i386 dpkg-dev:i386 apt-doc:i386
  python-apt:i386 glibc-doc:i386 locales:i386
The following packages will be REMOVED:
  apt dpkg
The following NEW packages will be installed:
  apt:i386 dpkg:i386 gcc-4.7-base:i386 libapt-pkg4.12:i386 libbz2-1.0:i386
  libc6:i386 libc6-i686:i386 libgcc1:i386 libselinux1:i386 libstdc++6:i386
  zlib1g:i386
WARNING: The following essential packages will be removed.
This should NOT be done unless you know exactly what you are doing!
  apt dpkg
0 upgraded, 11 newly installed, 2 to remove and 0 not upgraded.
Need to get 10.3 MB of archives.
After this operation, 16.1 MB of additional disk space will be used.
You are about to do something potentially harmful.
To continue type in t

Re: amd64 as default architecture

[Goswin von Brederlow]

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 reducing even
> that to a 'partial architecture' that has only libraries (similar to
> ia32-libs today, only cleaner).
>
> Ben.

Which basically means i386 is droped but we still support 32bit stuff
for amd64.

Isn't there still a large demand for i386 in the industry/embedded
sector?

MfG
Goswin



-- 
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/87396fnyhz.fsf@frosties.localnet

Re: why do people introduce stup^Wstrange changes to quilt 3.0 format

[Goswin von Brederlow]

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 to understand.
> Is there a VCS workflow which would make such packages easier to manage 
> than with quilt? (I like quilt, BTW.)
>
> -- 
> ciao,
> Marco

Check out gitpkg. It has hooks to create the quilt patches from a set of
feature branches in some form.

Also note that in this scheme where you produce a single debian patch
you would not be working on the single debian patch. You would still
work on your 30-60 feature branches (or whatever else you use instead of
a patch queue). The single debian patch would just be the fallback for
people that can't access your VCS.

The single patch would be hard to understand but it would be unfair to
compare it to 30-60 patches in a patch queue. What you have to compare
the single patch with is a single debian diff.gz. Obviously if you can
make a meaningfull patch queue with seperate patches that is
preferable. The single patch method is for situations where you can't.

MfG
Goswin


-- 
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/87y5o7mj4t.fsf@frosties.localnet

Re: debuild/dpkg-buildpackage behaves not as expected

[Goswin von Brederlow]

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? From the Debian policy, I don't see a
>>> need why sources should kept untouched during the build process.
>>
>> Less surprises by someone unfamiliar with the source. For example:
>>
>> - you (as in some porter, not the maintainer) build the source to
>>   reproduce a FTBS 
>> - it fails as expected
>> - you edit the broken file
>> - you build again and it works
>> - you call clean so you can make a patch
>> - clean restores the original source file destroying hours of your
>>   work
>
> If I would be unfamilar with the source, I would just not expect that
> the package behaves as I would do it myself. Instead, I would be ready
> for the case that it does tricky, undocumented things with the source --
> and create the debian patch before I am going to build the package.
>
> Why should a porter expect more from a package than the requirements
> specified in the policy?

Because I'm an optimist. When I work on a new source package I naively
assume that the source is nice and does no evil, ugly, hackish things.
Obviously that leaves me disapointed when it does.

But all of that doesn't mean a source isn't better if it doesn't do
evil, ugly, hackish things. Policy might not require it but common sense
encourages it.

>>> It is just the better design: the package was built with a patched
>>> source, so only the patched version knows for sure how to clean it up. 
>
>> Note that it only calls clean with unpatched sources if you
>> specifically unpatched your source before calling it.
>
> If you insist so much on this standard: why does debuild (or
> dpkg-buildpackage) undo the patches if they were not applied before? In
> this case, it would be up to the (rare) people to unpatch if they need
> this. One could even provide a debuild/dpkg-buildpackage option for that
> (like --unpatch-after-build or so), or do it in a hook.

There already is the uapply-patches option. But then the patch is always
unpatched after build instead of returning to the state prior to build.

>> So I think having the clean target make sure patches are applied if
>> needed is the better design.
>
>  which again does not behave as expected: if "clean" depends on
> "patch", then after "debuild clean" the packages is in the "patched"
> state even if it was unpatched before. 

Yes, if you just depend on patch then that is the result.

clean:
$(PATCH)
clean up everything
$(UNDO_PATCH)

where PATCH is a makro that records the current patch state (like dpkg
itself does) and UNDO_PATCH a makro to return the patch state to what
was saved. I haven't tried this but you can probably make those makros
use exactly the state file and format dpkg uses for abest results.

> 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 state
you had before the dpkg-buildpackage was called.

> way that is described as "standard" for Debian), with a special option

Which means that if you start with the "standard" of patches applied
then they will remain applied. But if you manually deviate from the
"standard" then it will preserve that deviation too.

> or hook that does this for those who really need it (and know what they
> are doing).

Which would mean that you would have to unapply patches every time you
try to build while working on a patch. With the current behaviour I can
do

quilt push foo.patch   (foo.patch being somewhere in the middle)
edit file
quilt refresh
debuild
edit file
quilt refresh
debuild
edit file
quilt refresh
debuild

>> I was describing the case of having changes commited to the RCS and
>> generating debian/patches/* automatically (or a single debian-changes
>> patch).
>
> A single debian-changes patch is evil -- even Lintian complains there. 
> Handling a single debian-changes patch is something I would explicitely
> *not* take as a valid use case.
>
> Is there a way to automatically handle a bunch of individual patches
> trough an RCS?

git-pkg has something for that for example.

> Best regards
>
> Ole

MfG
Goswin


-- 
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/87txyvmidm.fsf@frosties.localnet

Re: zlib and biarch/triarch

[Goswin von Brederlow]

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, and will remain doing so for some time, builds biarch
(multilib) and needs any number of Build-Depends.

MfG
Goswin


-- 
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/87pq9jmi7u.fsf@frosties.localnet

Re: Moving /tmp to tmpfs makes it useless

[Goswin von Brederlow]

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.

Even without load it is much faster because fsync() becomes a NOP. Disk
based filesystems add sequenze points where you have to wait for the
disk to catch up before continuing while tmpfs does not.

It also saves on wear of the disk if the files are small and short
lived, like temp files for gcc. No point writing the file to disk if it
gets deleted 10s later.

>> the point. Maybe we should add a /small-files-on-tmpfs (choose
>> a better name, of course...) folder so that apps know what to do,
>> that'd be a lot more graceful than just switching to whole /tmp
>> to tmpfs without any app knowing about it.
>
> Nice idea, but it would be worthless.
>
> In fact it is the other way.  We have /var/tmp for the large file since
> about forever, and important platforms that have /tmp in memory since the
> early 2000's (Solaris)
>
> And that STILL wasn't enough for people to not screw it up and dump large
> files in /tmp.

There is also no problem with having large files in tmpfs. Only
requirement is that you make tmpfs large enough and add enough ram
and/or swap to cope with it.

All the complaints about /tmp as tmpfs come down to one simple issue:
The size of the tmpfs isn't chosen well. It would be more constructive
to find a better heuristic for the size there.

MfG
Goswin


-- 
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/87lik7mhl9.fsf@frosties.localnet

Re: Moving /tmp to tmpfs makes it useless

[Goswin von Brederlow]

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 filesystem IO load, yes it is.  By several orders of magnitude.
>> 
> This is a corner case.
>
> Defaults should be sane for most of the cases, and not for corner cases.
> Also defaults should prioritize stability (and non-breakage) over
> performance.
>
> With "tmpfs on /tmp" you are breaking many applications that assume that
> they have enough space to write on /tmp like the flash player ( see
> Debian bug #666096 ) or cdrecord software ( see #665634 ).

And again, tmpfs isn't breaking it, only the size of /tmp. A 1GB real
/tmp filesystem breaks them just like a 1GB tmpfs breaks them.

So make /tmp large enough. Improve the heuristic that defines the size
for tmp.

> The FHS [2] does not define *nothing* about the size of /tmp or
> /var/tmp. It *only* says that programs using files under /tmp must not
> assume that this files are preserved between invocations of the program
>
>
> So please, *stop* saying that /tmp should be only for small files
> because this is simply *not* *true*. It is *not* defined on any standard
> that files on /tmp should be small. Period.

It is also *not* defined on any standard that files on /tmp may be
big. Period.

Sorry, that argument simply cuts both ways.

An application that stores files in /tmp without checking size and/or
handling ENOSPC properly is just broken and needs to be fixed
regardless.

MfG
Goswin


-- 
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/87hauvmgwm.fsf@frosties.localnet

Re: Moving /tmp to tmpfs makes it useless

[Goswin von Brederlow]

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 scenario:
>> - An app writes in /tmp
>> - There's not enough space, so the system starts swapping,
>> including some apps.

Which happens regardless wether tmp is tmpfs or a real filesystem. The
more IO there is the more likely some app gets swapped out.

>> - The file gets written to /tmp, then gets read
>> - Finally, the file gets deleted

With tmps that instantly frees up all the memory and swap used by the
file. With a real FS the file data remains in the dirty cache until such
a time as the disk has cought up with writing it all and then it is
thrown away. So potentially memory is freed up much later.

>> - Then we have randomly very sloppy reaction of apps
>> that were swapped out so that the file could be written
>> in /tmp.

Which, without tmpfs, then has to additionaly first wait for the dirty
cached data to be written out causing huge delays because you get two
seeks per page, 4k read/writes and no read-ahead.

> I believe tmpfs memory is swapped out preferentially, so your scenario
> doesn't have to play out like that. However, paging being a complex
> process, it's not impossible either. Is that something people are
> actually seeing? Because I haven't encountered this. 

It happens. But that isn't to say it doesn't equally (or worse) happen
with a real FS.

Paging is a complex process and there are so many factors involved that
predicting the behaviour becomes pure guesswork. I would say both Thomas
and my scenario are equally likely to occur. No matter what the default
is there will be some users that hit the worst case.

MfG
Goswin


-- 
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/87d35jmgf9.fsf@frosties.localnet

Re: Moving /tmp to tmpfs makes it useless

[Goswin von Brederlow]

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 large files are
>>>written faster when they're written on real disk, rather then swapped
>>>out and slow down the entire system (see the "Who uses /tmp" part).
>>>The apps that can really benefit from tmpfs are too rare. And we're
>>>talking about default settings and most common cases.
>> 
>> Any application which writes synchronously (through fsync(), fdatasync(), or 
>> opening with O_SYNC) will get a massive performance benefit from using tmpfs.
>
> If some kind of sync is required by the application, I think this is
> because the application want to ensure the data are really written to
> the disk so that their state remains coherent even in case of crash.
>   If the application is ok to have this kind of data written to
> tmpfs (ie in memory), I do not see the interest of using sync at
> first. Can someone shows me a valid use case of sync on tmpfs?
>
>   Regards,
> Vince

You might also need to [fm]sync() to ensure the data written by one
application can be read by another, to ensure the state remains coherent
between multiple processes.

And don't forget that disk based filesystems add syncs internally to
ensure their own coherent state. Applications do get blocked by those
too.

MfG
Goswin


-- 
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/878vg7mg4h.fsf@frosties.localnet

Re: debuild/dpkg-buildpackage behaves not as expected

[Olе Streicher]

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 state
> you had before the dpkg-buildpackage was called.

It does not since it keeps the compiled files. If you mean it serious
with "restoring the state", you should call clean here, too.

>> or hook that does this for those who really need it (and know what they
>> are doing).
> Which would mean that you would have to unapply patches every time you
> try to build while working on a patch. With the current behaviour I can do
>
> quilt push foo.patch   (foo.patch being somewhere in the middle)
> edit file
> quilt refresh
> debuild
[...]

You can do the same even if either "clean" is called before the
unpatching was done, or if neither clean nor unpatching was done, since
quilt recognizes the state.

The point is really: The state
* compiled files (*.o etc.) from a patched package, but
* unpatched source files
is inconsistent. 

Best regards

Ole



-- 
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/ytzsjef6zu1@news.ole.ath.cx

Re: Moving /tmp to tmpfs makes it useless

[Goswin von Brederlow]

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 thread doing the write will just write to cache and not block
at all. That is until you run out of cache. And then any thread that
needs to allocate memory will block until such a time as some dirty
memory is written.

Now with multiple cores it becomes a bit more complex since then you
have seperate queues. So only one core might block anything needing
memory on that core.

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.

MfG
Goswin


-- 
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/874nqvmfwu.fsf@frosties.localnet

Re: Moving /tmp to tmpfs makes it useless

[Goswin von Brederlow]

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 disk will only block the thread performing the 
>>> write, not every thread that tries to allocate memory.
>> 
>> What IO scheduler are you using?  It must not be CFQ.  CFQ will happly
>> screw it up and stall both readers and writers when the number of dirty
>> pages gets too large (which will happen if you write a gigabyte file to
>> disk).
>> 
>> Either that, or you're cheating and your backend devices are simply "fast
>> enough" that it doesn't matter (fast RAID or fast SSD).
>> 
>> The real question is: what does it better under CFQ+IO contention?
>> Several threads doing filesystem IO, or the swapper?  Hint: it is not an
>> easy question to answer because it depends on the load, type of load,
>> and backend device.
>> 
>
> I think that any user that has been using Linux for a while knows how
> ugly the things become when the systems starts swapping.
>
> When the system is swapping, the whole system will become so
> unresponsive while the swapping process is taking place that even your
> mouse pointer will stop moving.
>
> And this is *very* *very* annoying.
>
> This is so annoying, that I even had configured my laptop with a very
> low amount of swap, since I rather prefer the oom-killer to kill the
> application that is filling the ram than rather suffer this annoying
> situation.
>
> So please, don't argue about theoretical things about virtual memory or
> IO schedulers. If you are a desktop Linux user, you should know how ugly
> the things get when the system is swapping.

That is swapping out binaries or their data and needing to wait for it
to be swapped back in. The problem is the waiting for it to be swapped
in there, not that you are swapping.

With large data on tmpfs you will be swapping out lots of data but you
won't block waiting for stuff to be swapped back in in general. Only
something reading back the file will block, not your mouse cursor.

> 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's a matter of that gets swapped and linux choosing the wrong thing to
swap (far too often). There is some "bug" in linux that when you have
lots and lots of IO at some point the swap heuristics tip over and start
swapping apps and usefull data to create more cache space for
IO. Doesn't matter that you already have 3GB for cache, it still swaps
out your mouse cursor and then things go real bad.

MfG
Goswin


-- 
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/87zk8nl10x.fsf@frosties.localnet

Re: May be ITP: mime-support-extra to close #658139 (Was: Breaking programs because a not yet implemented solution exists in theory)

[Andreas Tille]

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:  Just add the according mime file as
> > .mime and add  to "Enhances" in debian/control.
> 
> I don't think adding such a package is a good idea. It's just an ugly
> work-around.

Fully ACK.  That's why the first of the option what could be done was to
leave it as local package and do not upload it officially.

> In http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=497779 there is
> already a patch by brian m. carlson. Any effort regarding this issue
> should be spent getting this patch ready and applied to mime-support.

I would consider the severity of this bug to low considering that
several applications are broken if we will not fix this problem before
the next stable release.  Is there anything which prevents an upload of
this fix?  If there would be no soonish upload I'd consider increasing
the severity to make sure it will not be forgotten somehow.

Kind regards

Andreas.

-- 
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/20120601113352.gd31...@an3as.eu

Re: Moving /tmp to tmpfs makes it useless

[Goswin von Brederlow]

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.
>- Ted

No, tmpfs will be swapped out if you don't use a file for a while but
something else uses memory, including IO caching. The difference to a
disk based filesystem is that most disk based filesystems force the
write out after a short wait (1-60s).

MfG
Goswin



-- 
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/87vcjbl0ma.fsf@frosties.localnet

Re: Moving /tmp to tmpfs makes it useless

[Goswin von Brederlow]

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 is unnecessarily
>> rewritten to disk rather than just dropped. Thus, if you do multiple
>> read iterations through a large set of data (which does not fit in
>> memory) on tmpfs, each iteration does disk read AND write rather than
>> just read.
>
> I don’t know enough of the kernel innards, but it sounds to me that if a
> previously swapped page hasn’t been modified, it should be kept on swap
> *and* memory as long as possible. 
>
> If it does not, it sounds like a bug, but it would indeed lead to the
> behavior you describe for this specific usage pattern.

Linux certainly has a notion of cached swap, i.e. pages from swap that
are also unmodified in memory. As long as you have enough swap the
kernel should not reap the swapped data and know that it is already on
disk when it wants to evict the page.

MfG
Goswin


-- 
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/87r4tzl0ik.fsf@frosties.localnet

Re: Moving /tmp to tmpfs makes it useful

[Goswin von Brederlow]

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 "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87hauvkzl0.fsf@frosties.localnet

Re: Idea: mount /tmp to tmpfs depending on free space and RAM

[Goswin von Brederlow]

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 (which [...] may have lots of free space or very
>> little). [...] consider tmpfs mounted on /tmp: the size specifies the
>> total available space.
>
> Well, technically, we already guarantee that. The option TMP_OVERFLOW_LIMIT
> does. It mounts /tmp to tmpfs if there's too few free space there. But we
> can make it better.
>
> Idea:
>   mount /tmp to tmpfs only when amount of free space in /tmp is fewer
>   than amount of RAM.

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.

> Technical details:
> 0. fstab is already processed and /tmp was (or was not) mounted to a
>separate partition.
> 1. init-script cleans it (since it must clean it anyway)
> 2. and then compares `df /tmp/` with amount of RAM available.
> 3. If amount of RAM is larger it mounts /tmp to tmpfs
> 4. otherwise leaves /tmp as it is.
>
> This way we can guarantee that there will be as much space in /tmp as
> possible but *at least* as much as the amount of RAM available.
>
> Looks reasonable? Will that suit everyone?

No.

If /tmp is already mounted as a seperate partition then tmpfs should not
be mounted. It might be neccessary to mount a tmpfs if the remaining
size in /tmp is less than TMP_OVERFLOW_LIMIT. This case would only occur
if the seperate /tmp filesystem is broken in that it can't be cleaned.

With people doing stupid things like using just one partition you easily
have 3TB free in / and therefore /tmp. Actualy having less space in /tmp
than tmpfs would get would be quite rare. So tmpfs would basically never
be used despite the benefits.

Even non stupid setups can have lots of space in /. Specifically when
you have /usr on / instead of a seperate partition. Having a few GB free
there is quite reasonable. Still a tmpfs makes more sense.

Even worse / can be read-only and then you always need a tmpfs for /tmp
or a seperate partition.

Or maybe I just like tmpfs and have configured my system to set the
right options in /etc/default/tmpfs. You are completly ignoring that
configuration.



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 too small to be usefull. For some user that would be
100MB, for others it is 100GB.

Best I can come up with is that applications that need lots of space in
/tmp, which are few, could check in postinst and give a debconf notice
that /tmp should be resized according to
/usr/share/doc/something/README.tmp-resize to at least xGiB.

> IMHO: this option should not break anything (and may even fix something)
> so it can be enabled by default. But it MUST be possible to disable it for
> those rare cases when admin intentionally left /tmp on a small partition.

Your option would make all my systems unbootable since / is read-only,
includes /usr and has some GB free space.

MfG
Goswin


-- 
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/87d35jkyvq.fsf@frosties.localnet

Re: amd64 as default architecture

[Ben Hutchings]

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 the i386 arch?
> >
> > No, keep i386 userland only.  Though we might consider reducing even
> > that to a 'partial architecture' that has only libraries (similar to
> > ia32-libs today, only cleaner).
> >
> > Ben.
> 
> Which basically means i386 is droped but we still support 32bit stuff
> for amd64.
> 
> Isn't there still a large demand for i386 in the industry/embedded
> sector?

I don't know; nor whether they use Debian much.  But those are two
sectors not well known for keeping their software updated, i.e. they
might not care about a lack of future releases..

I'm not suggesting there's any need to decide a timescale for this,
anyway.   I'm just proposing that we plan to have that transitional
stage for some time before actually removing i386.

Ben.

-- 
Ben Hutchings
The obvious mathematical breakthrough [to break modern encryption] would be
development of an easy way to factor large prime numbers. - Bill Gates


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

Re: Moving /tmp to tmpfs makes it useless

[Roger Leigh]

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 small has unreasonable expectations
> >>> of what can be expected to be available (by default).
> >>>   
> >> We welcome you to rewrite / patch these software then!
> >> Good luck, the list is huge, and growing every day this
> >> thread is alive.
> > 
> > (As an aside, could you possibly reduce the number of mails you're
> >  sending.  You've sent at least 12 today, and most of them all
> >  said essentially the same thing.)
> 
> I'll do that when people will stop ignoring arguments posted on the very
> first message of the thread, like the fact so many popular applications
> are writing big files to /tmp, and that it's simply unrealistic to
> believe we can fix them all before Wheezy. You seem to forget it once
> more in this post as well.

Nothing in this thread has been ignored.  Please don't make unwarranted
assumptions.  Stating the same thing in 20 different replies doesn't
make it any more useful than stating it in one.  I'm well aware of the
issues involved and haven't "forgotten" anything.

> > The primary cause of problems is simply that the tmpfs /tmp isn't
> > big enough.  Applications are creating files which use up all the
> > space.  I'd like us to consider the problem in terms of 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, and there is a single filesystem (which might be
> > very large or quite small, and may have lots of free space or
> > very little).  In this case, we offer no guarantees about the
> > available space.  Now in the typical case, we might well have
> > tens, or even hundreds, of GiB available, which can be used by
> > files under /tmp.  But this is not guaranteed.  There might be
> > next to no free space.  Now consider tmpfs mounted on /tmp: the
> > size specifies the total available space.  This is guaranteed to
> > be available; it's both the minimum and maximum, so while it /might/
> > place a lower upper limit on size than a regular filesystem would,
> > it also guarantees that this space will be available
> 
> Unless I didn't understand how tmpfs work, you have no guarantee as
> well. Once your memory is eaten by apps, and your swap gets full, you
> are in the exact same situation as having your /tmp holding partition
> full, at the exception that your system becomes totally unusable and
> unstable.

The defaults have been carefully (perhaps even too conservatively)
chosen to prevent any problems with the system becoming unusable.
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.  You are *guaranteed* to be able to use that
space, and it does not cause problems (modulo the size limit being
too small).  The important point is that the space is absolutely
guranteed to be available, which is something a regular filesystem
does not, unless you dedicate a separate filesystem to /tmp.


Regards,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linuxhttp://people.debian.org/~rleigh/
 `. `'   schroot and sbuild  http://alioth.debian.org/projects/buildd-tools
   `-GPG Public Key  F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800


-- 
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/20120601123246.gn...@codelibre.net

Re: Moving /tmp to tmpfs makes it useless

[Roger Leigh]

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 particularly new to add to the discussion here.

[This was also posted to LWN in part.]

As mentioned in
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=674517 it was
originally intended that this feature only be enabled for new
installs, not on upgrade. As mentioned in this bug, some of that has
been rectified already in git. We will also correct the configuration
for users who got tmpfs enabled during upgrade, but this needs careful
testing. The main issue for it being enabled on upgrades is that
insufficient swap may be available to have a reasonable amount of
space. This is also an issue for new installs--we do need some support
in the installer for this as well.

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. As
was seen in both this an earlier discussions, there is not a clear-cut
consensus here--there are from what I can tell approximately equal
numbers in the "for" and "against" camps. It's clear we can't satisfy
everyone no matter which is picked as the default.

As mentioned, the use of tmpfs really boils down to peoples
expectations of what /tmp is /for/. The size of what may be stored
isn't specified in any standard, so it's not fair to say that it's
only usable for "small" files. But using a tmpfs does place a
restriction of the size of the files which may be used. That said,
allowing certain applications to store multi-GiB files on /tmp causes
its own indirect problems in addition to the immediate: these programs
are often broken on smaller systems due to not being able to cope with
running out of space, and impose a requirement for vast amounts of
temporary space.  These programs are broken on systems with a smaller
rootfs, irrespective of the tmpfs issue.

Maybe we need to distinguish not on size, but on speed of access, and
have /tmp for "fast" access and a separate location for slower
disc-backed storage, which would be more suited to the storage of
streaming media, ISO images etc. which are going to have a longer
lifetime, and also tend to be larger. None of these uses benefit from
being on a tmpfs in the general case. (I've used /scratch for this in
the past, though currently it's a 1 TiB btrfs RAID1 under
/srv/scratch.)  Obviously out of scope for wheezy.

The important part of what we've achieved for wheezy is having tmpfs
filesystems mounted on /run (and optionally /run/lock and /run/shm).
The tmpfs on /tmp uses the same infrastructure in our init scripts,
and we mount tmpfs on /tmp in two special cases: if the rootfs is
read-only and no /tmp mount exists in fstab, and if /tmp contains less
than a certain amount of free space. This is one part of making it
possible to run with a read-only rootfs out of the box, and also to
aid recovery if booting when the rootfs is full, respectively.

The default of whether we mount tmpfs on /tmp by default or not is
really only a minor part of the other improvements we have in
wheezy--it really doesn't matter which is the default, so long as it
works. While I'm in favour of this being tmpfs, if there are too many
programs which break which can't be fixed, then we'll have to switch
back to using a regular filesystem. Maybe we'll then be able to
reconsider it for wheezy+1.

[As an ironic aside, when testing RAMTMP=no in rcS for backward
compatibility for #674517, I ran out of space on /tmp and broke
gcc/ld.  On my system, there's only a few hundreds of MiB free on
the rootfs; tmpfs is absolutely needed here!]


Regards,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linuxhttp://people.debian.org/~rleigh/
 `. `'   schroot and sbuild  http://alioth.debian.org/projects/buildd-tools
   `-GPG Public Key  F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800


-- 
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/20120601124026.go...@codelibre.net

Re: Debian documentation permalinks

[Philip Ashmore]

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 wrote:
>>  Hi there.
>>
>>  First, here's what I'm talking about -
>>  http://en.wikipedia.org/wiki/Permalink
>>  Unfortunately Wikipedia doesn't offer permalinks itself, so
>>  hopefully the above link won't "rot".
>
>  And here's the permalink to the above article, as it was when the
>  preceding post was made:
>  http://en.wikipedia.org/w/index.php?title=Permalink&oldid=483438630
>  Or, if you prefer links that don't indicate where they're really
> going: http://en.wikipedia.org/w/index.php?oldid=483438630

  I'm happy and sad with this.
  Happy that Wikipedia provides permalink support.
  Sad that it didn't document it in its article about permalinks.

  Is there documentation on this feature somewhere?

  Permalinks, along with the fact that MediaWiki is free GPLv2,
 makes a compelling argument for moving Debian documentation to
 MediaWiki.
>>>
>>>  Which documentation are you talking about? Most official
>>> documentation should have a fixed URL.
>>>
>>>  If you are talking about the wiki: retrieving a fixed version from
>>>  moinmoin is the same as in mediawiki.
>>>
>>>  So I can't see a useful argument here, only FUD trying to talk
>>> people into using Mediawiki.
>>>
>> Hi there and thanks for your feedback.
>>
>> I'm talking about the fact that Debian has mail archives that may
>> include links to documentation that has changed since the mail was
>> written, possibly rendering the mail thread misleading or nonsensical.
>>
>> Any documentation system that can provide a means to refer to a
>> specific version (permalinks) would be better than what's there now.
>
> Could you give examples of things lacking permalinks?
> thanks,
> kk
>
http://wiki.debian.org/BridgeNetworkConnections

It doesn't mention which version(s) of Debian it applys to.
It doesn't provide links to versions that apply to previous or testing 
versions

of Debian.
I also couldn't find a permalink on the page.

Oh and I couldn't get it to bridge from my wifi to the ethernet port.

Does anyone else out there wish there was an app that (graphically) 
simulated

packet flow/filtering based on test configurations?
This page is definitely not noob-friendly, or is that a feature?

Philip


--
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/4fc8bf4e.4070...@philipashmore.com

Re: Moving /tmp to tmpfs makes it useless

[Salvo Tomaselli]

> 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 pressure on the RAM, which is absolutely not as 
aboundant as disk space is a mistake, for a generic configuration.
If you know that you aren't going to hit that high memory allocation then.. 
free to use tmpfs.

-- 
Salvo Tomaselli


-- 
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/201206011510.52802.tipos...@tiscali.it

Bug#675467: ITP: bilibop -- run Debian from external media

[bilibop project]

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 from external media

Bilibop is a collection of scripts using or used by other programs (initramfs-
tools, udev, aufs, mount, GRUB2) to help admins to maintain a Debian GNU/Linux
operating system installed on a removable and writable media. One of its main
goals is to fix security issues or harden standard rules and policies to make
the system more robust in this particular situation.

The bilibop source package builds the following binaries:

bilibop: metapackage

bilibop-common: shell functions to find the drive hosting the root filesystem
(dm-crypt, LVM, loop devices, aufs and any combination of them are supported)

bilibop-rules: udev rules to fix the removable drive hosting the running
system, and all its partitions, as members of the 'disk' group (fixes bug
#645466). Other optional features for the desktop environment (based on
Udisks).

bilibop-lockfs: make a standard installation to behave like a LiveUSB. Can be
used as an alternative (and enhancement) of the fsprotect package.



-- 
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/20120601131051.5723.72626.reportbug@xporter

Re: Moving /tmp to tmpfs makes it useless

[Salvo Tomaselli]

> 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 pressure the kernel 
starts doing odd choices.

So the point is: is it correct to enforce a default setting that will break 
many software that would otherwise work flawlessy, and that makes the machine 
less reliable but faster for certain kind of tasks?

-- 
Salvo Tomaselli


-- 
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/201206011513.46456.tipos...@tiscali.it

Re: Debian documentation permalinks

[Ben Hutchings]

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 AM, Jonathan Callen wrote:
>  >  On 05/25/2012 10:03 PM, Philip Ashmore wrote:
>  >>  Hi there.
>  >>
>  >>  First, here's what I'm talking about -
>  >>  http://en.wikipedia.org/wiki/Permalink
>  >>  Unfortunately Wikipedia doesn't offer permalinks itself, so
>  >>  hopefully the above link won't "rot".
>  >
>  >  And here's the permalink to the above article, as it was when the
>  >  preceding post was made:
>  >  http://en.wikipedia.org/w/index.php?title=Permalink&oldid=483438630
>  >  Or, if you prefer links that don't indicate where they're really
>  > going: http://en.wikipedia.org/w/index.php?oldid=483438630
>  
>    I'm happy and sad with this.
>    Happy that Wikipedia provides permalink support.
>    Sad that it didn't document it in its article about permalinks.
>  
>    Is there documentation on this feature somewhere?
>  
>    Permalinks, along with the fact that MediaWiki is free GPLv2,
>   makes a compelling argument for moving Debian documentation to
>   MediaWiki.
>  >>>
>  >>>  Which documentation are you talking about? Most official
>  >>> documentation should have a fixed URL.
>  >>>
>  >>>  If you are talking about the wiki: retrieving a fixed version from
>  >>>  moinmoin is the same as in mediawiki.
>  >>>
>  >>>  So I can't see a useful argument here, only FUD trying to talk
>  >>> people into using Mediawiki.
>  >>>
>  >> Hi there and thanks for your feedback.
>  >>
>  >> I'm talking about the fact that Debian has mail archives that may
>  >> include links to documentation that has changed since the mail was
>  >> written, possibly rendering the mail thread misleading or nonsensical.
>  >>
>  >> Any documentation system that can provide a means to refer to a
>  >> specific version (permalinks) would be better than what's there now.
>  >
>  > Could you give examples of things lacking permalinks?
>  > thanks,
>  > kk
>  >
> http://wiki.debian.org/BridgeNetworkConnections
> 
> It doesn't mention which version(s) of Debian it applys to.
> It doesn't provide links to versions that apply to previous or testing 
> versions
> of Debian.

It's a wiki, so how would we ensure that?

> I also couldn't find a permalink on the page.
> 
> Oh and I couldn't get it to bridge from my wifi to the ethernet port.

Not particularly surprising; that recipe is a nasty hack.  Routing makes
more sense.

> Does anyone else out there wish there was an app that (graphically) 
> simulated
> packet flow/filtering based on test configurations?
> This page is definitely not noob-friendly, or is that a feature?

It's a wiki, so how would we ensure that?

Ben.

-- 
Ben Hutchings
The obvious mathematical breakthrough [to break modern encryption] would be
development of an easy way to factor large prime numbers. - Bill Gates


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

Re: Moving /tmp to tmpfs makes it useless

[Salvo Tomaselli]

> 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.  You are *guaranteed* to be able to use that
> space
swap is shared between every process, it's not for tmpfs only... so there is 
no such thing as *guaranteed*.

-- 
Salvo Tomaselli


-- 
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/201206011605.48078.tipos...@tiscali.it

Re: Moving /tmp to tmpfs makes it useless

[Serge]

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--there are from what I can tell approximately equal
> numbers in the "for" and "against" camps.

I don't see the "for" camp. I only see the "against" and "not against".
People from "against" camp list the problems. And others from "not against"
camp are saying that "it's not that bad". Nobody shown why it's a good
default yet.

Can you name arguments from the "for" camp, or at least quote them? What
software became faster/better because of tmpfs? Just some popular software
that anybody can run and say "wow, it's twice faster with /tmp on tmpfs".
None, then why forcing it?

> Maybe we need to distinguish not on size, but on speed of access, and
> have /tmp for "fast" access and a separate location for slower
> disc-backed storage

Why do you call /tmp on tmpfs "fast"? Does it make anything faster?
If not then what's the point in reinventing /tmp in a separate location?

> [As an ironic aside, when testing RAMTMP=no in rcS for backward
> compatibility for #674517, I ran out of space on /tmp and broke
> gcc/ld.  On my system, there's only a few hundreds of MiB free on
> the rootfs; tmpfs is absolutely needed here!]

Ehm... A few questions, I'm just curious:
1. Don't you use -pipe option for gcc?
2. How have you managed to fill "a few hundreds of MiB" with gcc!?
3. What do you think about default RAMTMP=auto idea: in addition to the
RAMTMP=no and RAMTMP=yes implement RAMTMP=auto value: mounting /tmp to
tmpfs only when this increases free space in /tmp? Meaning, if you have
more than 20%VM free space in /tmp on disk, than no tmpfs mounted
(the "Idea: mount /tmp to tmpfs depending on free space and RAM" mail)?
It would solve the problem of small root and at the same time all the
"tmpfs problems" will go away.

-- 
  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/CAOVenEreZE=ov=07aiclrju6hx1m6dkmw_2+on6w-ffqlrp...@mail.gmail.com

Re: Debian documentation permalinks

[Philip Ashmore]

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://wiki.debian.org/BridgeNetworkConnections

 It doesn't mention which version(s) of Debian it applys to.
 It doesn't provide links to versions that apply to previous or testing
 versions
 of Debian.


 It's a wiki, so how would we ensure that?

By mentioning which version(s) of Debian it applies to.



 I also couldn't find a permalink on the page.

 Oh and I couldn't get it to bridge from my wifi to the ethernet port.


 Not particularly surprising; that recipe is a nasty hack.  Routing makes
 more sense.


 Does anyone else out there wish there was an app that (graphically)
 simulated
 packet flow/filtering based on test configurations?
 This page is definitely not noob-friendly, or is that a feature?


 It's a wiki, so how would we ensure that?

Ok, I guess I'm being off topic here - I'm talking about a Debian package that
can
1. Accept the same configuration files/syntax as the "real" services do.
2. Allows the user to describe some hypothetical networking set-up, possibly
   involving multiple networking interfaces on multiple machines.
   Also, network manager interactions should be visible too.
3. Can identify the kinds of packets that each machine would be expected to
   send / accept based on role options (DHCP, wifi, Gateway, non-configurable)
   configurable with dialogs.
4. Can display a simulation of the packets being routed/forwarded/rejected based
   on the configuration
5. Can generate scripts to be run on one or more of the target machines
   (that run Debian?) to verify a particular configuration deployment among the
   target machines.


 Ben.


Philip


--
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/4fc8cfed.4090...@philipashmore.com

Re: support for installing unconfigured systems (VM images, Debian Live images, preinstalled mobile/tablet images)

[Paul Wise]

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 have created OEM images, it might be interesting to
digg into these if anyone is interested in implementing this for
Debian:

http://blog.linuxmint.com/?p=2046

-- 
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/CAKTje6EBp3Fkg9h1GH=ekuozvchom8m-ws1tonscdyjaa+q...@mail.gmail.com

Re: Idea: mount /tmp to tmpfs depending on free space and RAM

[Serge]

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 added.

>> Looks reasonable? Will that suit everyone?
>
> No.

:'-(

> If /tmp is already mounted as a seperate partition then tmpfs should
> not be mounted.

Hm... Good point. Debian should not try to be smarter than admin. If admin
specified a mountpoint for /tmp then it must be used whatever size it is.

> It might be neccessary to mount a tmpfs if the remaining
> size in /tmp is less than TMP_OVERFLOW_LIMIT. This case would only occur
> if the seperate /tmp filesystem is broken in that it can't be cleaned.

Yes, I guess so.

> With people doing stupid things like using just one partition you easily
> have 3TB free in / and therefore /tmp. Actualy having less space in /tmp
> than tmpfs would get would be quite rare.

This idea comes from an attempt to make everything work for small root
partitions without breaking things that were working before.

> So tmpfs would basically never be used despite the benefits.

Well, nobody named the benefits yet. Just the problems. There were a
few attempts with some artificial test scripts, but no examples of real
applications becoming faster with /tmp on tmpfs. And it's kind of
pointless to change the defaults just to make some useless scripts faster.

I could try finding a better solution if I knew the benefits.

> Or maybe I just like tmpfs and have configured my system to set the
> right options in /etc/default/tmpfs. You are completly ignoring that
> configuration.

Or course, if you set the option it must be used. I was not suggesting to
force that, just add one more option. For example in addition to RAMTMP=yes
and RAMTMP=no add value RAMTMP=auto, and make it default value. So if you
set RAMTMP=yes you'll get tmpfs (whatever you set in fstab). But if you
don't set it you'll get "auto" behavior.

> In general your option assumes that you need the maximum amount of free
> space in /tmp. That is simply not true.

It should solve all the "tmpfs" problems listed in the thread and break
nothing. That was the goal.

> In most cases a small /tmp is just peachy.

In *some* cases I would say. But I see nothing good in a small /tmp for
default debian users. :)

> Because of this it is hard to set a minimum size where
> tmpfs would be too small to be usefull. For some user that would be
> 100MB, for others it is 100GB.

I assume that it's still possible to change default options. I.e. you're
free to change RAMTMP and TMP_SIZE to your needs.

> Best I can come up with is that applications that need lots of space in
> /tmp, which are few, could check in postinst and give a debconf notice
> that /tmp should be resized

One of those "few" applications is "tar", used by mc. I can't suggest a
proper tmpfs size for it. ;)

> Your option would make all my systems unbootable since / is read-only,
> includes /usr and has some GB free space.

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 cleans it (since it must clean it anyway)
2. and checks `df /tmp/` for free space and partition
3.a. if RAMTMP == yes or RAMTMP == no then goto 4
3.b. if RAMTMP != auto then print a warning
3.c. if /tmp is not writable then RAMTMP=yes; goto 4
3.d. if /tmp is not on a root partition then RAMTMP=no; goto 4
3.e. if has_less_than_TMP_SIZE_free_space then RAMTMP=yes; goto 4
3.f. else RAMTMP == no
4. if RAMTMP == no and has_less_than_TMP_OVERFLOW_LIMIT_free_space
   then RAMTMP=yes
5. if RAMTMP == yes then mount /tmp to tmpfs

Maintainer will probably write a better code.

PS: Have you thought about mount-binding /tmp to /home/tmp for
your read-only root systems? Or your /home partition isn't local?

-- 
  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/CAOVenEpy-zwzyKB7MYsGb=xCB6sBPAKD6uyDDVRF9GnrZ1=o...@mail.gmail.com

Re: Orphaning php-codesniffer, then take it over by the PHP PEAR team

[George Danchev]

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 do away with
> sponsorship and require the uploader to be either Maintainer or in
> Uploaders unless it's an NMU (note: I don't think this is what we want).

I don't think this is that black and white indeed. In the case of unresponsive 
non-DD maintainer, obviously the Sponsors (having more powerful pedals and 
knobs than the sponsoree wrt to the archive) have several courses of action 
(in no particular order; various combinations are also possible):

* step in and maintain the package themselves
* ask for help, search for co-maintainers, etc
* suggest orphanage
* you name it

and I guess this is a very basic, but fairly sufficient measure to handle the 
the case of run-away non-DD maintainers.

-- 
pub 4096R/0E4BD0AB 


-- 
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/201206011806.53799.danc...@spnet.net

Target path variables in debian/rules

[Ole Wolf]

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

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.

What should I write instead of ${mandir} to get the proper path (so that
the entire path on my particular system becomes
debian/packagename/usr/share/man/man1/packagename.1)?

-- 
Ole Wolf
Rødhættevej 4 • 9400 Nørresundby
Telefon: 9632-0108 • Mobil: 2467-5526 • Skype: ole.wolf



smime.p7s
Description: S/MIME cryptographic signature

Re: Idea: mount /tmp to tmpfs depending on free space and RAM

[Stephan Seitz]

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 too small to be usefull. For some user that would be
100MB, for others it is 100GB.


/tmp is for temporary files, so I expect my /tmp to hold all these files, 
in my case DVD ISO images (downloaded or localy generated) that I will 
burn and then delete. So my /tmp is at least 20GB. BluRay users may need 
more.


If this is not the meaning of /tmp, then rename it.

Diskspace is cheap and easier to spare than my RAM. So, yes, if someone 
has one 3TB partition which is writeable, then /tmp belongs to disk not 
to RAM.


Shade and sweet water!

Stephan

--
| Stephan Seitz  E-Mail: s...@fsing.rootsland.net |
| Public Keys: http://fsing.rootsland.net/~stse/keys.html |


smime.p7s
Description: S/MIME cryptographic signature

Starting services automatically after install

[Aaron Toponce]

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
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 would be as follows:

1. Install package
2. Configure service
3. Start service

Instead, I find myself doing a lot of:

1. Install package
2. Stop service
3. Configure service
4. Start service

I only bring this up, because I recently booted into a Debian Live 6.0.4
image, and found 32 (thirty-two!) services listening on external
interfaces, including port 6667! Further, ISC DHCP tried starting, although
it failed. Why is a DHCP server trying to start on a rescue tool?! Why is a
rescue tool running any services at all?! Especially ones listening on
external interfaces!

Anyay, that's off-topic. 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, before starting the service.

I would be interested in the opinions of the rest of the development
community on this, and why Debian handles services the way it does
currently. For comparison, Fedora and Red Hat Enterprise Linux do not start
a service after install. {Free,Open,Net}BSD start some, but never on
external interfaces. AFAIK, Arch Linux does not any services by default
after installation. . It seems that only Debian-based operating systems do.

Thanks,

-- 
. o .   o . o   . . o   o . .   . o .
. . o   . o o   o . o   . o o   . . o
o o o   . o .   . o o   o o .   o o o


-- 
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/20120601172242.ge12...@kratos.cocyt.us

Re: Maintainer responsible for or only doing maintenance?

[Jonas Smedegaard]

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.
> 
> To me it is obvious that the sponsor is also responsible for a 
> package, when the maintainer become unresponsive or missing.  When the 
> maintainer is active and available, the sponsor do not have to step in 
> and the responsibility is "sleeping". :)
> 
> The maintainer is responsible in the day to day maintenance, but when 
> I sponsor packages I also keep in mind that I might end up having to 
> care about the package some time in the future if the listed 
> maintainer looses interest or disappears for other reasons.
> 
> You seem to argue that this should not be the case.  Is this because
> of your current sponsor practice, or is there some other experience
> behind your view on the responsibilities of a package sponsor in
> Debian?

I do not mean to say that sponsors should not be held responsible for 
maintenance, just that such responsibility *currently* isn't obvious - 
as e.g. Bernd seems to argue - and that I find that problematic.

I read Policy as defining Maintainer as _socially_ responsible entity, 
and Uploader as optional _sub-entity_ when Maintainer cannot also hold 
_technical_ responsibility.  Sponsoring breaks that logic, but I believe 
we can restore it by treating sponsoring exactly the same as we do 
teamwork.  Let me try to explain...:


Once upon a time we had maintainers that maintained and was held 
responsible for that.  Back then I found it sensible that the 
"Maintainer:" field was prominent throughout our tools - it was 
hardcoded into each source and binary package (not resolved through 
network queries via e.g. PTS web pages or who-uploads), and appears in 
e.g. aptitude.

Today I find the Maintainer field a joke.

In the future I would like Debian to again use the Maintainer field to 
indicate who is *responsible* for maintenance.

So yes, this is tied to my sponsor practice: I don't do sponsoring (in 
the common sense of the term), but (when we cannot find a suitable 
existing team to join) form a two-person team with me as Maintainer and 
the non-Debian-member as Uploader. That makes only the Uploader field 
somewhat a joke, similar to how it commonly is for teamwork nowadays.

In my opinion a person outside of the Debian WoT does not make sense as 
a Maintainer, exactly because failures go unnoticed: Sponsors ought to 
take responsibility but are not on display so if they forget (or even 
worse, don't care) then we may only discover it much later in frustrated 
threads like this one.

Debian is not a company. We don't pay the work done in money, and don't 
fire people not performing well.  Instead, Debian is a social organism 
where work is "paid" or "punished by your name being prominently tied to 
your work.  Problem is, if you are not hanging out in Debian social 
circles you don't feel the encouragement/pressure of your name on Debian 
billboards.  And even if you do, others in Debian have trouble locating 
you, because you are not tied to our WoT.  Please note that the 
reliability of the WoT is not the issue here - only the practicality of 
those email addresses being uniquely identifiable and cross-referenced 
in our structures so who is who is easily identifiable.

Some may argue that I steal fame from the person doing the actual work 
on the package.  I feel that I take fame (or shitstorm) of 
_responsibility_ of the package maintenance, and whoever doing the 
underlying _changes_ are documented in changelog.  If my fellow 
unofficial maintainer later wants to apply for becoming DM or DD, proof 
of her/his actual contributions and skills in packaging is clearly 
tracked.


I find sponsoring to be a hack, causing responsibility of maintenance to 
get blurred, with the consequence of packages going unmaintained too 
silently too easily.

Also, I find that sonsoring is not needed: Anything done in sponsoring 
can be done by teamwork instead.  Sure, for those sponsoring today 
feeling that their only responsibility is to _upload_ will feel that 
teaming up with the sponsoree instead is more responsibility - and that 
is exactly the point: sponsoring *is* more responsibility than just 
uploading, and today it is not clear, because we tag our sponsorees as 
maintainers even if in reality they (in my optic) cannot truly carry 
that role.


I truly and sincerely hope that I am not stepping on the toes of 
non-Debian folks doing packaging work.  That is absolutely not my intent 
- on the contrary I would want to make it more clear who is doing what 
and with which responsibility attached.


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

Re: Moving /tmp to tmpfs makes it useless

[Uoti Urpala]

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 again, it is unnecessarily
> >> rewritten to disk rather than just dropped. Thus, if you do multiple
> >> read iterations through a large set of data (which does not fit in
> >> memory) on tmpfs, each iteration does disk read AND write rather than
> >> just read.

> Linux certainly has a notion of cached swap, i.e. pages from swap that
> are also unmodified in memory. As long as you have enough swap the
> kernel should not reap the swapped data and know that it is already on
> disk when it wants to evict the page.

I haven't read the relevant kernel code, but that doesn't match the
behavior I see. Reading a large file from tmpfs and then allocating
memory results in large swap writes every time, even if the newly
allocated memory is not itself immediately swapped out and the file
should already be in swap from before.

The script below can be used to test the behavior. It creates a file,
then loops alternatively reading the file and allocating+freeing memory.
It's noteworthy that sometimes the read performance also drops over
iterations (maybe the swap layout becomes more fragmented?). I used the
given sizes for testing on a machine with 8 GiB memory. This load does
run faster on ext4 than tmpfs.

#!/usr/bin/python3

FILESIZE = 50
MEMSIZE  = 65
FILENAME = '/tmp/alloctest'

from time import time

def main():
print("creating file")
t = time()
with open(FILENAME, 'wb') as f:
ss = FILESIZE
while ss:
s = min(ss, 100)
f.write(b'x' * s)
ss -= s
print("file creation time: %.1f" % (time() - t))
i = 0
while 1:
print("iteration %d, reading file" % i)
i += 1
t0 = time()
t = t0
with open(FILENAME, 'rb') as f:
while f.read(100):
pass
print("file read time: %.1f" % (time()-t))
print("filling memory")
t = time()
s = b'x' * MEMSIZE
print("memory fill time: %.1f" % (time()-t))
t = time()
b'aaa' in s
del s
print('memory read time: %.1f' % (time()-t))
print("total time: %.1f" % (time()-t0))
print("press return for next iteration")
input()

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/1338571137.21597.28.camel@glyph.nonexistent.invalid

Re: Orphaning php-codesniffer, then take it over by the PHP PEAR team

[Jonas Smedegaard]

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 
> > doesn't care to maintain.  If this is the case, we should just do 
> > away with sponsorship and require the uploader to be either 
> > Maintainer or in Uploaders unless it's an NMU (note: I don't think 
> > this is what we want).
> 
> I don't think this is that black and white indeed. In the case of 
> unresponsive non-DD maintainer, obviously the Sponsors (having more 
> powerful pedals and knobs than the sponsoree wrt to the archive) have 
> several courses of action (in no particular order; various 
> combinations are also possible):
> 
> * step in and maintain the package themselves
> * ask for help, search for co-maintainers, etc
> * suggest orphanage
> * you name it
> 
> and I guess this is a very basic, but fairly sufficient measure to 
> handle the the case of run-away non-DD maintainers.

Sorry if I am dense, but those pedals and knobs look like maintenance 
ones to me: Simply relabel the sponsor as maintainer as Scott 
(non-)proposes and it _is_ black and white to me.

I am genuinely interested in understanding the reasons for labeling 
sponsoree rather than sponsor as maintainer.  Could you (or anyone) 
elaborate on that?


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: Digital signature

Re: Starting services automatically after install

[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 secure 
> the service to my liking, before starting the service.

Debian goal is - as you probably know already - for packages to work out 
of the box.  For daemons this means they are started by default.

If a package (service or not) is insecure by default, it is a bug! 
Severity of such bugs vary - e.g. some may consider it insecure for a 
web server to publicly display a static page saying "It works!" while 
most probably won't.

You can override the default of daemons using policy.d.

What I do for chroots  - which you can adapt to your own personal needs, 
is to install the package policyrcd-script-zg2 and add the attached 
config file as /usr/local/sbin/policy-rc.d .


Hope that helps,

 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private
#!/bin/sh

# $Id: policy-rc.d,v 1.5 2007-01-16 09:59:43 jonas Exp $
#
# Copyright © 2006 Jonas Smedegaard 
# Description: Suppress system V scripts if invoked within a chroot.
#
# This program is free software; you can redistribute it and/or
# modify it under the terms of the GNU General Public License as
# published by the Free Software Foundation; either version 2, or (at
# your option) any later version.
#
# This program is distributed in the hope that it will be useful, but
# WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
# General Public License for more details.

# Policy-rc.d is mentioned in manpage invoke-rc.d(8) and documented at
# http://people.debian.org/~hmh/invokerc.d-policyrc.d-specification.txt

set -e

PRG=`basename $0`

TEMP=`getopt -s sh --long list,quiet -n "$PRG" -- "$@"`
if [ $? != 0 ] ; then echo "Terminating..." >&2 ; exit 1 ; fi
eval set -- "$TEMP"

# Stolen from udev postinst
chrooted() {
	if [ "$(stat -c %d/%i /)" = "$(stat -Lc %d/%i /proc/1/root 2>/dev/null)" ];
	then
		# the devicenumber/inode pair of / is the same as that of /sbin/init's
		# root, so we're *not* in a chroot and hence return false.
		return 1
	fi
	return 0
}

quiet=""
list=""
while true ; do
	case "$1" in
		--quiet) quiet="1" ; shift ;;
		--list) list="1" ; shift ;;
		--) shift ; break ;;
		*) echo "Internal error!" ; exit 1 ;;
	esac
done
initscript="$1"
actions="$2"
runlevel="$3"

if [ "$list" ]; then
	cat <&2 "Chroot environment detected, suppressing sysV script."
	fi
	exit 101
fi

exit 0


signature.asc
Description: Digital signature

Re: Starting services automatically after install

[Philip Hands]

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 certainly going to result in a long and pointless thread,
to go with a long series of similarly long and pointless threads. *sigh*

> I would be interested in the opinions of the rest of the development
> community on this, and why Debian handles services the way it does
> currently. For comparison, Fedora and Red Hat Enterprise Linux do not start
> a service after install. {Free,Open,Net}BSD start some, but never on
> external interfaces. AFAIK, Arch Linux does not any services by default
> after installation. . It seems that only Debian-based operating
> systems do.

The reason that RedHat don't start things is that their default approach
has been to install a whole load of stuff that you might possibly want,
and allow you to enable it when you are inspired to give some new
service a try.

The Debian approach has always been to not install anything that you
don't intend to use.  It is also to ensure that if you do choose to
install something, it should be doing something useful by the end of the
install (if possible, security considerations allowing).

That is also why Debian and RedHat diverge when it comes to prompting
the user for configuration questions -- RedHat just want the software to
install, whereas Debian wants it to be useful, so may need to ask
questions.

It also leads to the fact that you can do major release upgrades of
Debian, whereas that's not really supported in RedHat, as chances are
your configuration is going to get trashed to some extent, and they
don't have the chance to ask you what you want to do about it.

Both approaches are valid, and are mostly a matter of taste.  If you
are using a distribution that uses one assumption, it's not useful to
start introducing packages that work on the opposite assumption.

If you don't like the assumptions, you are much better off switching to
a distribution that you prefer, rather than trying to persuade the
overwhelming majority of the people that like the current assumptions,
and use Debian because of those assumptions, that they should change
their minds because they are supposedly wrong for liking it that way.

Cheers, Phil.
-- 
|)|  Philip Hands [+44 (0)20 8530 9560]http://www.hands.com/
|-|  HANDS.COM Ltd.http://www.uk.debian.org/
|(|  10 Onslow Gardens, South Woodford, London  E18 1NE  ENGLAND


pgp2qZzklgqK0.pgp
Description: PGP signature

Re: Orphaning php-codesniffer, then take it over by the PHP PEAR team

[Steve Langasek]

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 MIA process has been
> setup is because many DD fear forcibly taking over or forcibly orphaning
> a package. So instead of relying on random DD to do it, we put up some
> best practice procedure and a team to handle this.

> But this process is not set in stone, and if a DD believes that the best
> course of action is to orphan/take over a package, he should certainly be
> free to do it all by him/herself.

> Informing the MIA team for tracking purpose is still a good idea, though.

So I should probably clarify, because I misspoke in my previous message.  By
"MIA process" I was not merely referring to the process used to determine
that a Debian developer is MIA and should have their account expired; I was
also referring to the longstanding process of discussing package orphaning
on the QA mailing list, and having the QA team make a determination that a
package is de facto maintainerless and should be orphaned.

The important thing here is still that the decisions are made by consensus
within the QA *team*, not as a decision by a single developer who decides to
take over the package.  This is an important check on developers deciding in
the moment that their particular pet issue should trump our conventions.

So no, I stand by my statement that an individual DD should not take it upon
themselves to decide that a package should be orphaned.  This sort of thing
needs to be a community decision.

On Thu, May 31, 2012 at 01:08:11PM +0100, Ian Jackson wrote:
> Steve Langasek writes ("Re: Orphaning php-codesniffer, then take it over by 
> the PHP PEAR team"):
> > A hijack is, by definition, a declaration by the hijacker that they believe
> > they are not answerable to the project's processes for how package
> > maintenance is decided.  It is antisocial vigilanteism and it is not
> > acceptable.

> Our processes for how package maintenance is decided are utterly
> dysfunctional.

> If the TC had _ever_ voted to remove a maintainer who wanted to keep
> hold of a package, it might be at least reasonably possible to argue
> that the TC was the right forum for these disputes.

> > As a sitting member of the Technical Committee, I encourage anyone who sees
> > a package being hijacked to immediately bring it to the attention of the TC.
> > I will without hesitation vote to have the hijacker barred from being made
> > the maintainer of the package.

> Instead of this kind of aggressive approach to those who are IMO quite
> reasonably working around our dysfunctional formal processes, how
> about working towards fixing those dysfunctional processes ?

> I await with interest your suggestions for revising the way the TC
> deals with problematic maintainers.  I have been arguing for years
> that we need a much more robust approach.

Right, so the constitution says that it's the TC that decides whenever
there's a question of maintainer.

But in practice, when one of the would-be maintainers is not doing the work
and not responding to email, I don't think there should be any need for the
formal process of a TC vote.  I think it's more than sufficient to get a
consensus on the mailing list that the maintainer isn't coming back, *after*
making an appropriate effort to contact the maintainer and waiting a
suitable amount of time for a response.  And indeed, this is the convention
that's been in place for approximately the past decade on the debian-qa
list.

The key points of this process are:

 - It's not a decision by an individual that the package can be orphaned
   (and silence does not imply consent).
 - An effort is made to actively contact the maintainer on the subject of
   orphaning, rather than assuming the maintainer's non-interest based on
   the state of bugs.
 - The maintainer is given a suitable amount of time to respond.  A week is
   not a suitably long waiting period.  Indeed, the minimum waiting period
   here should *at minimum* be longer than the longest NMU waiting period.
 - The orphaning does *not* go ahead over the maintainer's objection.  If
   the current maintainer objects, they should be persuaded by reasoning or
   the matter should be referred to the TC.

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 "hijack" clearly refers to a /hostile act/.  By definition,
anything that could legitimately be called a hijack should not be permitted;
and anything that we believe should be permitted should not be referred to
as "hijacking".  Otherwise, people will infer that all kinds of
inappropriate and hostile behavior is ok when it shoul

Re: Target path variables in debian/rules

[Jonathan Yu]

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 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)/debian/$(PACKAGE)

Using this method, you can substitute $(PACKAGE) for the package name,
which may make your rules file a little prettier...

Please see this page for this and other tricks:
http://pkg-perl.alioth.debian.org/debhelper.html#note_on_paths

Cheers,

Jonathan

Re: Orphaning php-codesniffer, then take it over by the PHP PEAR team

[Tollef Fog Heen]

]] 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 worthwhile addition to Debian.  I'm not
doing the actual maintenance, I'm reviewing parts of the maintenance
being done, and so giving me the maintainership would be wrong.  There's
both the «who should you talk to about this package» as well as
crediting the person who's doing the actual legwork.

(I'm talking about what I do here, I'm not saying this is the one and
only way to do sponsorship.)

Cheers,
-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are


--
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/878vg6olrq@xoog.err.no

Re: Starting services automatically after install

[Tollef Fog Heen]

]] 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 secure 
> > the service to my liking, before starting the service.
> 
> Debian goal is - as you probably know already - for packages to work
> out of the box.  For daemons this means they are started by default.

The problem here is of course for those that really need a bit of
configuration before they're usable.

[...]

> You can override the default of daemons using policy.d.

A problem with using policy-rc.d is you don't know whether a service
is being started because it's the initial install or if it's because of
an upgrade.  I'll sometimes not want the service to start on initial
installation (because chef is just about to plop its configuration into
place), but if it's an upgrade, then please just restart the service.

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are


-- 
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/874nquolif@xoog.err.no

Re: Starting services automatically after install

[Holger Levsen]

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: http://lists.debian.org/201206012211.58305.hol...@layer-acht.org

Re: Starting services automatically after install

[Jonas Smedegaard]

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 
> > > like to spend the necessary time as an administrator to configure 
> > > and secure the service to my liking, before starting the service.
> > 
> > Debian goal is - as you probably know already - for packages to work 
> > out of the box.  For daemons this means they are started by default.
> 
> The problem here is of course for those that really need a bit of 
> configuration before they're usable.
> 
> [...]
> 
> > You can override the default of daemons using policy.d.
> 
> A problem with using policy-rc.d is you don't know whether a service 
> is being started because it's the initial install or if it's because 
> of an upgrade.  I'll sometimes not want the service to start on 
> initial installation (because chef is just about to plop its 
> configuration into place), but if it's an upgrade, then please just 
> restart the service.

You could setup your local policy to check if the service exist in e.g. 
/etc/local-ok-services/ and then when you've customized or 
security-checked or whatever each service you do a

   touch /etc/local-ok-services/$service

Or did I misunderstand?

(We haven't spoken much in person, but I regard you as pretty clever so 
am surprised that you describe this as a problem and I feel it so simple 
to solve...)



Regards,

 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: Digital signature

why hijacking is bad (and salvaging is good) Re: Orphaning php-codesniffer, then take it over by the PHP PEAR team

[Holger Levsen]

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 "hijack" clearly refers to a /hostile act/.  By definition,
> anything that could legitimately be called a hijack should not be
> permitted; and anything that we believe should be permitted should not be
> referred to as "hijacking".  Otherwise, people will infer that all kinds
> of
> inappropriate and hostile behavior is ok when it shouldn't be.
> 
> And when people *do* engage in that kind of hostile behavior, yes, I think
> it should be referred to the TC and we should disapprove of it.  But when
> people are taking reasonable steps to confirm that a package is abandoned
> before taking it over - let's call this "salvage" - I have no problem with
> that; it should be encouraged and supported.

thanks for explaining, makes completly sense to me now! :-) 

(And I do think it's partly a language issue. For non-native speakers "hijack" 
is probably a bit more romantic and less obviously evil 8-)


cheers,
Holger

(And for those poor people (should they exist...) just reading my mail and not 
Steve's and thus having no idea what is ment with "salvaging a package": go 
read Steve's mail.)


-- 
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/20120601.16740.hol...@layer-acht.org

Re: why hijacking is bad (and salvaging is good) Re: Orphaning php-codesniffer, then take it over by the PHP PEAR team

[Paul Tagliamonte]

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 non-native speakers using the word differently,
>> but the word "hijack" clearly refers to a /hostile act/.  By definition,
>> anything that could legitimately be called a hijack should not be
>> permitted; and anything that we believe should be permitted should not be
>> referred to as "hijacking".  Otherwise, people will infer that all kinds
>> of
>> inappropriate and hostile behavior is ok when it shouldn't be.
>>
>> And when people *do* engage in that kind of hostile behavior, yes, I think
>> it should be referred to the TC and we should disapprove of it.  But when
>> people are taking reasonable steps to confirm that a package is abandoned
>> before taking it over - let's call this "salvage" - I have no problem with
>> that; it should be encouraged and supported.

I kinda like "Package reappropriation" myself :)

>
> thanks for explaining, makes completly sense to me now! :-)
>
> (And I do think it's partly a language issue. For non-native speakers "hijack"
> is probably a bit more romantic and less obviously evil 8-)
>
>
> cheers,
>        Holger
>
> (And for those poor people (should they exist...) just reading my mail and not
> Steve's and thus having no idea what is ment with "salvaging a package": go
> read Steve's mail.)
>
>
> --
> 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/20120601.16740.hol...@layer-acht.org
>



-- 
All programmers are playwrights, and all computers are lousy actors.

#define sizeof(x) rand()
:wq


--
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/CAO6P2QS07EHUODXJ=RdudQDzqBz88=DvhA1ad=7xzwdmcbf...@mail.gmail.com

Re: Orphaning php-codesniffer, then take it over by the PHP PEAR team

[Steve Langasek]

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 understand the
> mentioned mail),

So to be clear, no, I was not endorsing a hijacking of that package.  My
mail there was a response to an ill-considered defense of the current bacula
maintainer at that time.

I think I'm allowed to believe both that a package is not well-maintained,
and that developers shouldn't take matters into their own hands to resolve
such problems.

The bacula package *was* in bad shape at that time, and something needed to
be done.  That doesn't mean the particular "something" that was done -
starting a painful flamewar on debian-devel that led to the previous
maintainer deciding to walk away from the package (i.e., voluntarily
orphaning it after being demotivated) was the right thing to do.  However,
since the maintainer did walk away voluntarily, the TC didn't really have
grounds to intervene... and probably wouldn't have sided with him anyway, so
probably wouldn't have been less painful.

Many of the earlier "hijack" mails on debian-devel also followed a very
different process than the one described in the present thread (e.g.,
allowing an indeterminate amount of "time", resulting in the original
maintainer resuming maintenance of the package -
https://lists.debian.org/debian-doc/2006/09/msg00071.html); or resulted
in amicable resolutions, with the previous maintainer explicitly approving
the hijacking (https://lists.debian.org/debian-devel/2001/05/msg00183.html);
or were intercepted by someone in the know, who diverted the hijack to an
NMU (https://lists.debian.org/debian-devel/2006/07/msg00568.html).

Unfortunately, it seems this has served as precedent, and the message people
have taken away is that it's perfectly ok to hijack packages... when almost
none of the "hijacking" statements have ever resulted in anything of the
sort.

> is now on a killing spree.  All he is doing is to encourage people to give
> up their idea to improve Debian.

From hijacks to killing sprees...  yes, I definitely think there's a
language barrier of some kind here. ;)

-- 
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


signature.asc
Description: Digital signature

Re: Maintainer responsible for or only doing maintenance?

[Thomas Goirand]

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 written somewhere, but
at least I know one place where it's written the exact
opposite of what you are claiming (it took me quite some
time to remember where I read it...):

http://wiki.debian.org/DebianMentorsFaq#What_if_I_upload_a_package.2C_and_then_my_mentee_disappears.3F

And specifically:
"Having said that, this does create some extra work for people who
decide to work on QA."
Then later:
"maintainers and packages enter and exit Debian; it's part of a life
cycle. It's okay to upload mentees' packages knowing that you risk
going through an orphaning/adoption process later."

So, here, we have the wiki page from mentors.debian.net (which
is not authoritative, I admit) that says the exact opposite thing
of what you are telling (it says that an unmaintained package
would go to the QA team), and nothing in the policy or in the
developer's reference that agree with you.

Without taking any side, either you or the mentors.d.o wiki page
is wrong.

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/4fc92921.4040...@debian.org

Re: why hijacking is bad (and salvaging is good) Re: Orphaning php-codesniffer, then take it over by the PHP PEAR team

[Holger Levsen]

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...@layer-acht.org

Re: Starting services automatically after install

[Michael Biebl]

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 would be as follows:

There are some valid use cases why services should not be run
automatically after installation.
Historically, the information when to start a sysv service (start
priority) was encoded in the update-rc.d call in the maintainer scripts.
As a result, we've seen a lot of those dreadful /etc/default/
files with ENABLE/DISABLE flags.
We do have quite a few services which ship such ENABLE=false default
configuration.

With the switch to dependency based boot and encoding the relevant
information in the LSB header, it is much simpler to enable or disable
a service.
I think it would be great, if dh_installinit provided a new mode, where
it adds the necessary start/stop calls to the maintainer scripts but
ships the service disabled by default.
I.e. the service would be disabled after the initial installation, the
administrator configures and enables the service, and future updates
ensure that the service is restarted on upgrades as is usually done.

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: Orphaning php-codesniffer, then take it over by the PHP PEAR team

[George Danchev]

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.
> > > 
> > > 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 do
> > > away with sponsorship and require the uploader to be either
> > > Maintainer or in Uploaders unless it's an NMU (note: I don't think
> > > this is what we want).
> > 
> > I don't think this is that black and white indeed. In the case of
> > unresponsive non-DD maintainer, obviously the Sponsors (having more
> > powerful pedals and knobs than the sponsoree wrt to the archive) have
> > several courses of action (in no particular order; various
> > combinations are also possible):
> > 
> > * step in and maintain the package themselves
> > * ask for help, search for co-maintainers, etc
> > * suggest orphanage
> > * you name it
> > 
> > and I guess this is a very basic, but fairly sufficient measure to
> > handle the the case of run-away non-DD maintainers.
> 
> Sorry if I am dense, but those pedals and knobs look like maintenance
> ones to me: 

Maintaining a package via long series of non-invasive NMUs does not declare  
maintainership (I meant pedals as in sponsors are able to upload without their 
sponsoree). It is just inconvenient for both the maintainers and the end 
users, and should be a temporal measure in the ideal case (and yes, I know we 
have packages in the archive effectively maintained via NMUs for many years).

> Simply relabel the sponsor as maintainer as Scott
> (non-)proposes and it _is_ black and white to me.
> 
> I am genuinely interested in understanding the reasons for labeling
> sponsoree rather than sponsor as maintainer.  Could you (or anyone)
> elaborate on that?

Maintainer field is meaningless, it is very meaningful. Why not just think of 
it this way (hopefully this could make you sleep better :) - If a Maintainer 
field points to a non-DD entity and that entity disappears from the horizon, 
then a DD-entity (the Sponsor [1], the Safeguard if you want) should do 
something meaningful to help to resolve the situation. This is not to say that 
the DD-entity (the Sponsor) is then allowed to perform hostile acts and all 
sorts of unlawful interferences (e.g. a hijacks) in the terms of the Debian 
normative docs.

[1] http://udd.debian.org/sponsorstats.cgi

-- 
pub 4096R/0E4BD0AB 


-- 
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/201206012309.57302.danc...@spnet.net

Re: Orphaning php-codesniffer, then take it over by the PHP PEAR team

[Michael Biebl]

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 checked that its quality is
> good enough that I consider it a worthwhile addition to Debian.  I'm not
> doing the actual maintenance, I'm reviewing parts of the maintenance
> being done, and so giving me the maintainership would be wrong.  There's
> both the «who should you talk to about this package» as well as
> crediting the person who's doing the actual legwork.

Nod. This is basically the same I do when sponsoring a package. I
carefully review the package before the upload and that's about it.
I don't keep track of bugs that are filed against this package nor do I
start maintaining it / feel responsible for it.
If my upload fucked up other packages or created a mess in an ongoing
transition, then of course I would feel responsible sorting this out
together with the maintainer. But in the usual case a sponsored upload
is a one-time thing ( I do have regular sponsoree's though)

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: Moving /tmp to tmpfs makes it useless

[Carlos Alberto Lopez Perez]

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's a matter of that gets swapped and linux choosing the wrong thing to
> swap (far too often). There is some "bug" in linux that when you have
> lots and lots of IO at some point the swap heuristics tip over and start
> swapping apps and usefull data to create more cache space for
> IO. Doesn't matter that you already have 3GB for cache, it still swaps
> out your mouse cursor and then things go real bad.

This makes sense. Many times I have experimented this situation while
copying a large file from a quick device (hdd) to a very slow device
(cheap usb stick)

IMHO The logical way of behaving in such situation is to slow-down the
IO bandwidth of the processes that are filling the cache, by sending to
sleep any process that requests more IO while the cache is full instead
of trying to free RAM by swapping out things from the RAM to the swap.

Do you know any way to avoid (or mitigate) this? Perhaps some sysctl
variable?

Can't Linux be configured to just block (sleep) any process that
requests IO while the cache is full?

Perhaps a good idea would be to limit the cache size on a per-PID basis
and block (sleep) the pid while its cache is full.

Thanks!

Best regards!
-- 
~~~
Carlos Alberto Lopez Perez   http://neutrino.es
Igalia - Free Software Engineeringhttp://www.igalia.com
~~~



signature.asc
Description: OpenPGP digital signature

Re: Target path variables in debian/rules

[Ole Wolf]

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)/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 entirely off then, because in my original
rules file I used $(CURDIR) and a hard-coded package name.

The $(shell dh_listpackages) adds some additional generality, but I was
actually thinking that there might be some further generalization
options that might even eliminate the directory structure. That is,
although man pages currently go to /usr/share/man/man?/.+[0-8](.gz)?,
somehow I thought some "MANDIR" or similar variable would be more
appropriate. Still, I'm glad to learn it's Debian kosher to hard-code
the paths.

-- 
Ole Wolf
Rødhættevej 4 • 9400 Nørresundby
Telefon: 9632-0108 • Mobil: 2467-5526 • Skype: ole.wolf



smime.p7s
Description: S/MIME cryptographic signature

Re: Moving /tmp to tmpfs makes it useless

[Roger Leigh]

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 real disk, rather then swapped
>out and slow down the entire system (see the "Who uses /tmp" part).
>The apps that can really benefit from tmpfs are too rare. And we're
>talking about default settings and most common cases.

OK, some benchmarks were requested in this thread in a few places.
Can't find them again since they got lost in the volume of mail.  I
resisted doing any so far because I didn't feel that they would be
particularly informative, and also because the results would be fairly
predictable, and additionally because while tmpfs /can/ improve
performance, it's only one of the reasons why we might want to use it.


 Summary 

These tests were all performed on current unstable using a core2 quad
core system with ext4 and swap on LVM on a 1 TiB MD RAID1 PV, and
Btrfs internally using RAID1 over 2 1TiB partitions.  The system has 8
GiB RAM and 16 GiB swap, and a 4.8 GiB tmpfs on /tmp (using the
experimental initscripts default of 20%VM).  For all results, n=20
with error ± SEMean.  Stats were done in R.  5 passes were performed
before recording data to ensure consistency.

1) Checkout of several tags in a git repository

   tmpfs 11.17s ± 0.05s
   ext4  18.51s ± 0.60s
   btrfs 15.81s ± 0.29s

2) Building a package (sysvinit)

   tmpfs 20.08s ± 0.03s
   ext4  21.08s ± 0.03s
   btrfs 20.52s ± 0.03s

3) Unpacking of a large zip file

   tmpfs 12.45s ± 0.01s
   ext4  19.69s ± 0.52s
   btrfs 12.79s ± 0.32s

4) Unpacking of large uncompressed tarfile

   tmpfs  1.16s ± 0.00s
   ext4  17.61s ± 0.41s
   btrfs  5.12s ± 0.20s


So the outcome is fairly obvious.  I/O bound jobs perform superbly on
tmpfs; in examples 3 and 4, the times are for how long it takes to
unpack 1.2 GiB of data.  Without the overhead of uncompression, making
it largely CPU bound, tmpfs is the fastest by far.  The package build
is a combination of both I/O and CPU bound jobs, so the differences
aren't so big, while git is more I/O bound, again showing tmpfs to be
faster.  So if you're doing a lot of I/O, tmpfs is unquestionably
faster.  If you're almost entirely CPU bound, the benefit is marginal,
but still measurable.  If you're doing a mixture, you do see some
benefit, but you'll need to profile your specific case to determine
exactly how much.

Now, these are just four simple tests.  They deliberately use hot
caches, using several warm up runs to ensure that.  No unnecessary
swapping or disc activity should occur.  If you have a system which is
swapping, of course the tmpfs performance will drop, just as if you
have a lot of filesystem I/O, the I/O performance will also drop.
These are rather harder to test accurately and consistently, so I
haven't done this at present.  If anyone wants to, feel free.

The other caveat is that due to the use of hot caches, and lack of
explicit fsyncs, this will actually artifically inflate the performance
of the disc-based filesystems in the common case, since all of the data
being processed is in the buffer/page cache.  It's only measuring
writes.  So for most workloads, the performance of tmpfs is most likely
much better than reported here (by a factor of at least two, probably
quite a bit more).  These could be added; again, if anyone wants to
do that, please feel free.


Regards,
Roger


 Methods and results 

1) checkout of git repository

#!/bin/sh
set -e
for pass in $(seq 1 5); do
sh -c "for tag in v3.0 v3.1 v3.2 v3.3 v3.4; do git checkout \"\$tag\"; 
done"
done
for pass in $(seq 1 20); do
/usr/bin/time -f '%e' -a -o "$1" \
sh -c "for tag in v3.0 v3.1 v3.2 v3.3 v3.4; do git checkout 
\"\$tag\"; done"
done

> d
   tmpfs  ext4 btrfs
1  11.31 22.42 17.15
2  11.30 22.13 15.35
3  11.04 19.63 15.46
4  11.24 19.12 15.51
5  11.50 18.00 14.96
6  11.01 22.55 15.15
7  11.17 16.29 15.11
8  11.04 23.57 17.42
9  11.20 15.21 15.17
10 11.68 18.20 15.86
11 10.74 17.81 15.22
12 11.30 18.25 15.43
13 10.96 21.94 15.43
14 10.80 14.61 20.39
15 11.27 15.34 14.99
16 11.28 18.04 16.46
17 11.65 17.35 15.53
18 10.97 16.46 15.16
19 10.79 16.73 15.51
20 11.22 16.46 14.91
> sapply(d, mean)
  tmpfsext4   btrfs
11.1735 18.5055 15.8085
> sapply(d, semean)
tmpfs  ext4 btrfs
0.0583243 0.6044565 0.2855330


2) Building a package (sysvinit)

#!/bin/sh
set -e
for pass in $(seq 1 5); do
sh -c "dpkg-buildpackage -us -uc"
done
for pass in $(seq 1 20); do
/usr/bin/time -f '%e' -a -o "$1" \
sh -c "dpkg-buildpackage -us -uc"
done

> sb
   tmpfs  ext4 btrfs
1  20.11 21.06 20.56
2  20.13 21.28 20.58
3  20.15 20.90 20.46
4  19.82 21.01 20.52
5  19.94 21.03 20.83
6  20.06 21.09 20.43
7  20.06 21.19 20.48
8  19.94 20.82 20.38
9  20.16 21.00 20

Re: Target path variables in debian/rules

[gregor herrmann]

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 entirely off then, because in my original
> rules file I used $(CURDIR) and a hard-coded package name.

:)
 
> The $(shell dh_listpackages) adds some additional generality, but I was
> actually thinking that there might be some further generalization
> options that might even eliminate the directory structure. That is,
> although man pages currently go to /usr/share/man/man?/.+[0-8](.gz)?,
> somehow I thought some "MANDIR" or similar variable would be more
> appropriate. Still, I'm glad to learn it's Debian kosher to hard-code
> the paths.

That's fine, yes.

If you'd like to avoid the paths in debian/rules, you could also do
something like:

1) create the manpage in d/rules and save it under debian/:

override_dh_auto_build:
dh_auto_build
/script/to/create/manpage > $(CURDIR)/debian/manpage.1

2) let dh_installman install it:

echo debian/manpage.1 > debian/package.manpages 

3) make sure the generated manpage gets removed during clean:

echo debian/manpage.1 > debian/clean


More complicated than just writing it into the temporary
$(CURDIR)/debian/$(PACKAGE)/... path during build, but also works and
makes debian/rules shorter.


Cheers,
gregor, who prefers the first option

-- 
 .''`.  Homepage: http://info.comodo.priv.at/ - OpenPGP key 0xBB3A68018649AA06
 : :' : Debian GNU/Linux user, admin, and developer  -  http://www.debian.org/
 `. `'  Member of VIBE!AT & SPI, fellow of the Free Software Foundation Europe
   `-   NP: Rolling Stones: Lastime


signature.asc
Description: Digital signature

Bug#675528: ITP: ocl-icd -- Generic OpenCL ICD Loader

[Vincent Danjean]

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 : BSD
  Programming Lang: C
  Description : Generic OpenCL ICD Loader

This source package will provide two binary pakages:
Package: ocl-icd-libopencl1
Description: Generic OpenCL ICD Loader
 OpenCL (Open Computing Language) is a multivendor open standard for
 general-purpose parallel programming of heterogeneous systems that include
 CPUs, GPUs and other processors.
 .
 This package contains an installable client driver loader (ICD Loader)
 library that can be used to load any (free or non-free) installable client
 driver (ICD) for OpenCL. It acts as a demultiplexer so several ICD can
 be installed and used together.

Package: ocl-icd-dev
Description: Development files to build a ICD Loader
 OpenCL (Open Computing Language) is a multivendor open standard for
 general-purpose parallel programming of heterogeneous systems that include
 CPUs, GPUs and other processors.
 .
 This package provides a header file that allows a OpenCL implementation
 to build a installable client driver (ICD). With a ICD, an OpenCL
 implementation can be used by any OpenCL program without the need
 to link the program to the specific OpenCL implementation.


A few word about the context. There exist lots of OpenCL implementations.
A OpenCL program can either link to a specific OpenCL implementation
or it can link to a standardized libOpenCL library that allows the
program to dynamically choose the OpenCL implementation or even to
use several OpenCL implementations in the same program. In fact
libOpenCL is only a wrapper (more exactly a dispatcher) to
OpenCL implementations provided as ICD.
  ocl-icd is the only one (to my knowledge) free implementation of
such a ICD Loader. The main difficulty to implement it is that
all compatible ICD must provide a structure filled with OpenCL
function pointers, but there is no free documentation about the order
of these functions.
  So ocl-icd sources include tools to help to find this order from
closed-sources OpenCL implementations (by creating a fake OpenCL ICD
and letting the closed-source ICD Loader execute the faked functions).
Once the order is found, it is registered into a database. Vendors
ensure between them that functions are always at the same place so
the database is only filled when a new closed-source ICD Loader uses
more functions. Entries in the database are never modified nor
removed.
  ocl-icd also provides a header file declaring this structure of
function pointers so that any OpenCL implementation will be easily
able to provide an ICD. The goal is to add such an ICD to free
OpenCL implementation such as LIBCLC or clover.

  The Debian package will only use the database (ocl_interface.yaml
in the sources), so it will not have any non-free dependencies.
However, it needs opencl-headers that are currently in contrib.
  This is why I would ask opencl-headers maintainers to reconsider
the place of opencl-headers. If I understand correctly,
opencl-headers have been uploaded to contrib because their only
use case would be to compile an OpenCL program for a closed-source
OpenCL implementation (mainly amd or nvidia).
  Now, opencl-headers is required to compile this free ICD Loader.
And this free ICD Loader has all what is needed to compile a
free ICD from free OpenCL implementation.
  So, is it possible to upload opencl-headers to main instead of
contrib?

  Regards,
Vincent

PS: a preliminary package is on my 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/20120601223811.15142.94880.report...@eyak.imag.fr

Re: Orphaning php-codesniffer, then take it over by the PHP PEARteam

[Uoti Urpala]

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 people to do so (that is how I understand the
> > mentioned mail),
> 
> So to be clear, no, I was not endorsing a hijacking of that package.  My

> The bacula package *was* in bad shape at that time, and something needed to
> be done.  That doesn't mean the particular "something" that was done -
> starting a painful flamewar on debian-devel that led to the previous
> maintainer deciding to walk away from the package (i.e., voluntarily
> orphaning it after being demotivated) was the right thing to do.  However,
> since the maintainer did walk away voluntarily, the TC didn't really have
> grounds to intervene... and probably wouldn't have sided with him anyway, so
> probably wouldn't have been less painful.

I don't think the outcome can be accurately described as "voluntarily
orphaning it after being demotivated". He didn't really orphan it; he
only gave up trying to get it back after it had already been hijacked
and he could not find sponsors to upload his competing version.


> Many of the earlier "hijack" mails on debian-devel also followed a very
> different process than the one described in the present thread (e.g.,
> allowing an indeterminate amount of "time", resulting in the original
> maintainer resuming maintenance of the package -
> https://lists.debian.org/debian-doc/2006/09/msg00071.html); or resulted

The linked-to mail does not show such a resolution; changelog shows that
the original maintainer made one more upload, there was one NMU, and
then the would-be hijacker took over the package anyway.

> in amicable resolutions, with the previous maintainer explicitly approving
> the hijacking (https://lists.debian.org/debian-devel/2001/05/msg00183.html);
> or were intercepted by someone in the know, who diverted the hijack to an
> NMU (https://lists.debian.org/debian-devel/2006/07/msg00568.html).
> 
> Unfortunately, it seems this has served as precedent, and the message people
> have taken away is that it's perfectly ok to hijack packages... when almost
> none of the "hijacking" statements have ever resulted in anything of the
> sort.

In 3 of those 4 cases the maintainer did change. I think making extra
bureaucracy a hard requirement would likely have a negative total
effect, due to some desirable takeovers like the Bacula one not
happening at all as a result.


> > is now on a killing spree.  All he is doing is to encourage people to give
> > up their idea to improve Debian.
> 
> From hijacks to killing sprees...  yes, I definitely think there's a
> language barrier of some kind here. ;)

You seem to think it's a contradiction to both use a term with negative
connotations such as "hijack" to describe an action and to say that the
action is the right thing to do. I don't consider it contradictory. The
word "hijack" acknowledges that it is a controversial action, one which
you should expect to defend, and which perhaps wouldn't be required in
an ideal world. But it can still be the best choice in practice.



-- 
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/1338591082.21597.51.camel@glyph.nonexistent.invalid

Re: Moving /tmp to tmpfs makes it useless

[Ben Hutchings]

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 because I have experimented this situation myself more than a
> >> > couple of times.
> > It's a matter of that gets swapped and linux choosing the wrong thing to
> > swap (far too often). There is some "bug" in linux that when you have
> > lots and lots of IO at some point the swap heuristics tip over and start
> > swapping apps and usefull data to create more cache space for
> > IO. Doesn't matter that you already have 3GB for cache, it still swaps
> > out your mouse cursor and then things go real bad.
> 
> This makes sense. Many times I have experimented this situation while
> copying a large file from a quick device (hdd) to a very slow device
> (cheap usb stick)
> 
> IMHO The logical way of behaving in such situation is to slow-down the
> IO bandwidth of the processes that are filling the cache, by sending to
> sleep any process that requests more IO while the cache is full instead
> of trying to free RAM by swapping out things from the RAM to the swap.
> 
> Do you know any way to avoid (or mitigate) this? Perhaps some sysctl
> variable?
> 
> Can't Linux be configured to just block (sleep) any process that
> requests IO while the cache is full?
>
> Perhaps a good idea would be to limit the cache size on a per-PID basis
> and block (sleep) the pid while its cache is full.

I don't think it makes any sense to have a hard per-process limit.
Also, it's not generally possible to account dirty pages to specific
processes exactly.  But I think you will be pleased with this change
that was included in Linux 3.2:

http://lwn.net/Articles/456904/

Ben.

-- 
Ben Hutchings
We get into the habit of living before acquiring the habit of thinking.
  - Albert Camus


-- 
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/20120602000140.ge20...@decadent.org.uk

Re: Idea: mount /tmp to tmpfs depending on free space and RAM

[Bruce Sass]

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 cleans it (since it must clean it anyway)
> 2. and checks `df /tmp/` for free space and partition
> 3.a. if RAMTMP == yes or RAMTMP == no then goto 4
> 3.b. if RAMTMP != auto then print a warning
> 3.c. if /tmp is not writable then RAMTMP=yes; goto 4
> 3.d. if /tmp is not on a root partition then RAMTMP=no; goto 4
> 3.e. if has_less_than_TMP_SIZE_free_space then RAMTMP=yes; goto 4
> 3.f. else RAMTMP == no
> 4. if RAMTMP == no and has_less_than_TMP_OVERFLOW_LIMIT_free_space
>then RAMTMP=yes
> 5. if RAMTMP == yes then mount /tmp to tmpfs
> 
> Maintainer will probably write a better code.

Much better... if TMPTIME != 0 it will be necessary to mount the FS based 
/tmp, clean it, create a tmpfs, move anything left in /tmp to the tmpfs, then 
mount --bind the tmpfs on /tmp.

Keeping track of whether /tmp was FS or tmpfs based when the system last 
shutdown could be used to skip all that since RAMTMP=yes implies TMPTIME=0 
regardless of the setting in /etc/default/rcS.

- Bruce


-- 
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/201206011934.18503.bms...@shaw.ca

Re: pre-MIA quest for Patrick Winnertz (winnie-at-d.o)

[Miah Gregory]

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


-Original Message-
From: Bart Martens 
To: Mike Gabriel 
Cc: debian-devel@lists.debian.org, win...@debian.org
Subject: Re: pre-MIA quest for Patrick Winnertz (winnie-at-d.o)
Date: Fri, 1 Jun 2012 04:29:38 +
Mailer: Mutt/1.5.20 (2009-06-14)

On Thu, May 31, 2012 at 09:19:37PM +0200, Mike Gabriel wrote:
> Dear all,
> 
> I have been trying to contact Patrick Winnertz (winnie-at-d.o). I
> would like to see iTalc in Debian upgraded to 2.0

Relevant bug report from 3 September 2011:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=640200

> but Patrick is
> neither replying to contact attempts via mail (Debian Edu mailing
> list, directly), nor to contact attempts via IRC. My first attempt
> to reach  him is about 3-4 weeks ago.

That is a good reason to have a look at the MIA database.

Recent upload:
http://lists.debian.org/debian-devel-changes/2012/04/msg01990.html

Recent message on list:
http://lists.debian.org/debian-wnpp/2012/05/msg00180.html

So Patrick Winnertz is not MIA.

> 
> Earlier this year Patrick handed over the maintenance of slbackup /
> slbackup-php to me. This last contact was via IRC.
> 
> Has anyone heard from him, recently? If so, can you give him note to
> get in contact with me (or the Debian Edu team)?
> 
> If I do not hear from anyone on debian-devel@l.d.o within a week, I
> will contact the MIA team and request orphanage of italc.

I'm not sure but I don't think that the MIA team would orphan italc, because
Patrick Winnertz is not MIA.

It would be nice to get some feedback from Patrick Winnertz about this.

First priority is to fix the FTBFS bug 671489.  If you intend to update italc
to the newest upstream release, then please retitle bug 672636 to an intention
to NMU.

Regards,

Bart Martens




-- 
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/1338602555.5940.3.ca...@thinkpad3.darksilence.net

Re: why hijacking is bad (and salvaging is good) Re: Orphaning php-codesniffer, then take it over by the PHP PEAR team

[Thomas Goirand]

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 intended ! :)

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/4fc98a24.3020...@debian.org

Re: pre-MIA quest for Patrick Winnertz (winnie-at-d.o)

[Mike Gabriel]

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, http://das-netzwerkteam.de


- Original message -
> 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
> 
> 
> -Original Message-
> From: Bart Martens 
> To: Mike Gabriel 
> Cc: debian-devel@lists.debian.org, win...@debian.org
> Subject: Re: pre-MIA quest for Patrick Winnertz (winnie-at-d.o)
> Date: Fri, 1 Jun 2012 04:29:38 +
> Mailer: Mutt/1.5.20 (2009-06-14)
> 
> On Thu, May 31, 2012 at 09:19:37PM +0200, Mike Gabriel wrote:
> > Dear all,
> > 
> > I have been trying to contact Patrick Winnertz (winnie-at-d.o). I
> > would like to see iTalc in Debian upgraded to 2.0
> 
> Relevant bug report from 3 September 2011:
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=640200
> 
> > but Patrick is
> > neither replying to contact attempts via mail (Debian Edu mailing
> > list, directly), nor to contact attempts via IRC. My first attempt
> > to reach   him is about 3-4 weeks ago.
> 
> That is a good reason to have a look at the MIA database.
> 
> Recent upload:
> http://lists.debian.org/debian-devel-changes/2012/04/msg01990.html
> 
> Recent message on list:
> http://lists.debian.org/debian-wnpp/2012/05/msg00180.html
> 
> So Patrick Winnertz is not MIA.
> 
> > 
> > Earlier this year Patrick handed over the maintenance of slbackup /
> > slbackup-php to me. This last contact was via IRC.
> > 
> > Has anyone heard from him, recently? If so, can you give him note to
> > get in contact with me (or the Debian Edu team)?
> > 
> > If I do not hear from anyone on debian-devel@l.d.o within a week, I
> > will contact the MIA team and request orphanage of italc.
> 
> I'm not sure but I don't think that the MIA team would orphan italc,
> because Patrick Winnertz is not MIA.
> 
> It would be nice to get some feedback from Patrick Winnertz about this.
> 
> First priority is to fix the FTBFS bug 671489.   If you intend to update
> italc to the newest upstream release, then please retitle bug 672636 to
> an intention to NMU.
> 
> Regards,
> 
> Bart Martens
> 
> 
> 


-- 
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/1338610890.1455.2.camel@Nokia-N900