Re: Summary: Moving /tmp to tmpfs makes it useless

[Josselin Mouette]

Le mercredi 13 juin 2012 à 04:14 +0300, Serge a écrit : 
> Yes. Everything. Every popular /tmp usage that most users expect to work
> is limited either by CPU (gcc compiling) or by network speed (browser or
> flash temporaries), or is just too fast already (bash heredoc). So moving
> /tmp to tmpfs does not make them faster, but can break them instead (if
> there's not enough space to store a streamed video, for example).

You should really back up claims such as “GCC is CPU-bound” with data.

Because it sounds to me that when building with make -j8 on a fast
multi-core system, you will hit the IOPS limit of a rotating drive very
quickly.

(And please stop with this streamed video red herring. We do not choose
solutions based on bugs in proprietary applications, especially when no
actual solution will really work around that bug - you will always find
a case when a video fills your disk.)

-- 
 .''`.  Josselin Mouette
: :' :
`. `'
  `-


--
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/1339572149.4245.348.camel@pi0307572

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

[Bjørn Mork]

Serge  writes:

> Since tmpfs+swap is mostly slower than regular filesystem

And the world is flat.


Bjørn


--
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/874nqfn0af@nemi.mork.no

DEP-8 extension proposal: Add source package header

[Martin Pitt]

Hello all,

in Ubuntu we have started adding some autopkgtests to packages, using
the DEP-8 debian/tests/control standard [1]. We now also have a test
execution environment [2] which automatically triggers autopkgtest
runs for a package and all its reverse dependencies on each upload.
So far this is rather experimental.

The main problem that we are facing with this is that it is not easily
discoverable which source packages actually ship tests. Right now this
is a hardcoded list, which does not scale at all. Thus I would like to
propose to add a source package header, so that test execution
environments can find out packages with tests by merely scanning
Sources.gz (or iterating over the package dict with python-apt and the
like).

What do you think about something like this? (Diff against [3])

--- dep8.mdwn.orig  2012-06-13 09:22:06.156404163 +0200
+++ dep8.mdwn   2012-06-13 09:36:34.564446191 +0200
@@ -30,6 +30,14 @@
 currently implemented by the
 [autopkgtest](http://packages.debian.org/sid/autopkgtest) package.
 
+# Source package header
+
+To allow test execution environments to discover packages which provide tests,
+their source packages should have a "Has-Autotests: true" header. This can
+be set manually in debian/control with adding "XS-Has-Autotests: true" in the
+"Source:" paragraph. Future versions of dpkg-source might add this
+automatically when a debian/tests/control file is present.
+
 

I don't particularly care about the name or value of the header, but
it's important to agree on one so that we can avoid having to change
lots of packages later on.

Once this is in the standard and proven to work, I'm happy to send a
patch against dpkg-source to add that header automatically.

Thank you,

Martin

[1] http://dep.debian.net/deps/dep8/
[2] https://jenkins.qa.ubuntu.com/view/Precise/view/AutoPkg%20Test/
[3] http://anonscm.debian.org/viewvc/dep/web/deps/dep8.mdwn?view=markup
-- 
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)


signature.asc
Description: Digital signature

Bug#677319: ITP: pootle -- Web-based translation and translation management tool

[W. Martin Borgert]

Package: wnpp
Severity: wishlist
Owner: "W. Martin Borgert" 

Package name: pootle
Version : 2.1.6
Upstream Author : David Fraser, translate.org.za
URL : http://translate.sourceforge.net/wiki/pootle/index
License : GPL
Programming Lang: Python
Description : Web-based translation and translation management tool

 Pootle provides a rich set of features for managing a translation
 project.  It integrates components of the Translate Toolkit to provide
 error checkers for translation messages and the ability to download files
 in a number of formats: PO, XLIFF, CSV.  Pootle can also provide compiled
 PO files for download. You can use it to assign work to translators in
 your team, and you can define goals to help focus the efforts of your
 translation.  Pootle can run without a Web server or be proxied through
 your existing Apache server.  The Translate Toolkit is a set of software
 and documentation designed to help make the lives of localizers both more
 productive and less frustrating.

Pootle is available in squeeze, but removed from sid and wheezy
for lack of a maintainer. I don't like to maintain Pootle, but I
use it and unfortunately need it in wheezy. Help welcome!



-- 
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/20120613080236.5424.72727.report...@fama.tangosoft.com

Re: Moving /tmp to tmpfs makes it useless

[Goswin von Brederlow]

Josselin Mouette  writes:

> Le jeudi 07 juin 2012 à 15:48 +0100, Ben Hutchings a écrit : 
>> There's no need to be a dick about it.
>
> Because this discussion was all about not being a dick to begin with, of
> course.
>
> Remind me who, in absence of consensus, explained that if tmpfs was
> enabled by default, he would forcefully make d-i disable it, basically
> making all the effort useless?
>
> It is not new, but it still strikes me that some people in the project
> think that their privileges give them a right of veto against anything
> other people do.

So lets teach D-I about tmpfs and include it in a recipie as he
suggested now. Make that the default recipie and you will have your
revenge. :))

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

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

[Goswin von Brederlow]

Salvo Tomaselli  writes:

>> >But does the default have to be maximised for the dumbest possible user?
>> >Or should the default rather be for the intelligent user doing the right
>> >things?
>> 
>> But the intelligent user can change the default hisself, the dumbest
>> can’t. And Debian does allow the inexperienced user to install his
>> system.
>
> Sometimes people are intelligent but that doesn't mean that they are willing 
> to spend days just to fix these problems, maybe being intelligent doesn't 
> make 
> you interested in learning obscure switches for debian. (and knowing these 
> doesn't make one intelligent).
>
> So it's not about stupid users, it's about having a configuration that works 
> by default, without requiring people to go throu mailing lists to learn what 
> they need to install debian and have it working.

I agree with your argument but not your conclusion.

I think the focus should be more on intelligent users and to get
new/dumb users to become intelltigent. So the argument that intelligent
users can change the default is besides the point. They shouldn't have
to.

Also I'm too unwilling to spend days just to fix the stupid
partitioning. The default should be good enough for almost everyone. And
I have to argue that that means LVM with a few volumes. At least root,
swap, var and home. And leave plenty of free space so filesystems can be
easily grown as needed.

It will never be possible to have one default partitioning that will
perfectly suite everyone. So instead the goal should be to have a
flexible starting point that makes it easy to make it fit the users
needs, esspecially after the installation when a new user actually
figures out what is needed.

You say configuring the size of tmp is too hard because it is such a
black box thing you need days to figure it out. So why not focus on
making it easier? I already suggested that packages that need large
space in /tmp should check the size on install and point to a relevant
file documenting how to set the size for tmp better.

I would even go further and say that DI should figure out the initial
size/type for /tmp (and swap if tmpfs is used) based on the hardware and
packages it is going to install. Why shouldn't the default partitioning
differ for a desktop system and a mailserver? Isn't the partitioning
before knowing what will be installed later backward?

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

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

[Goswin von Brederlow]

Wouter Verhelst  writes:

> On Fri, Jun 01, 2012 at 07:00:52PM +0300, Serge wrote:
>> 2012/6/1 Goswin von Brederlow wrote:
>> > So tmpfs would basically never be used despite the benefits.
>> 
>> Well, nobody named the benefits yet.
>
> - You could mount your mail spool there, and make things go blazingly
>   fast [1]

Some month ago there was a /. article (sorry, don't have a link) about a
mail service achieving 99% compression on mail spools and being
balzingly fast speading mails like crazy. And yes, they keep all mails
in ram. Any disk access would just slow down spreading the mails around.

8-)

> - It speeds things up, especially on systems with loads of RAM and no
>   swapspace: whenever there's a possibility of disk access, no matter
>   how remote, you risk slowing things down due to that disk access.
>   Reducing disk access for things that don't need to be stored forever
>   is *good*.

On that note it also keeps the disk free to read/write other stuff. Like
the next input file or storing the final output file. On a cold cache
that can make a difference.

> - anything which reduces the number of possible disk accesses is good
>   for people using SSDs (I have a laptop with SSD, and no swap, and love
>   tmpfs for precisely that reason).
> - In the (on laptops and desktops) fairly common
>   "one-partition-for-everything" set-up, there's no risk of a runaway
>   process eating up your diskspace with huge files in /tmp and therefore
>   making it impossible for syslogd to write anything to disk anymore so
>   you can figure out what the f*** happened
> - It makes for an interesting "I need to compile something quickly just
>   to test something out" area, where it doesn't matter if you forget to
>   clean up after the fact (yes, this is a bit of an abuse of /tmp; never
>   the less, I find myself doing such things in /tmp fairly often now
>   that /tmp is a tmpfs)

Me too.

> - it's called *tmp*fs for a reason (no, that's not a benefit. Yes,
>   that's an argument in favour)
> - There's no danger of a symlink attack or similar with things like
>   tmpreaper -- or indeed any need for tmpreaper anymore. You reboot the
>   system, and /tmp is clean again, no matter what was there before. This
>   is more than just a convenience.

- No time wasted at boot to clean up /tmp. No journal replay, no fsck.

> [1] As demonstrated on FreeBSD in
> 
> .
> No, I'm not being serious.

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

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

[Goswin von Brederlow]

Bjørn Mork  writes:

> Petter Reinholdtsen  writes:
>
>> [Bjørn Mork]
>>> I'd like to add another one:
>>>
>>> - a tmpfs is always easy to grow without requiring any special
>>>   preparations.  Just add more swap.  The swap could be on different
>>>   disks, and could even be files hosted on other file systems.
>>
>> This sound very similar to what I am doing already with LVM and online
>> file system growing.  A simple 'lvresize' and 'ext2resize' (or just
>> debian-edu-fsautoresize for those of us with that tool available)
>> later the full file systems have more free space again. :)
>>
>> Did I misunderstand you?
>
> No, but those require LVM and available raw disk space.  Swap can always
> be added without any such preparation.
>
>
> Bjørn

And tmpfs is the only filesystem you can also shrink again.

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

Re: Handling of changelogs and bin-nmus

[Goswin von Brederlow]

Guillem Jover  writes:

> On Sun, 2012-06-10 at 14:40:28 +0200, Raphael Hertzog wrote:
>> On Sun, 10 Jun 2012, Guillem Jover wrote:
>> > As I mentioned in the long ref-counting thread, I strongly disagree this
>> > is a correct solution, it just seems like a hack to me. Instead I
>> > think we should consider changelog (and copyright as long as it's in
>> > machine parseable format) as dpkg metadata (something dpkg misses
>> > compared to rpm or other package managers for example) and as such they
>> > should go into the .deb control member, which would end up in the dpkg
>> > database w/o any kind of file conflict, and very minor packaging effort
>> > as for most that would be handled by helpers.
>> 
>> I agree that we should move into this direction. Still I believe it's
>> important to distinguish "source changelog" and "binary changelog".
>> And while we might not want to keep this distinction in the generated
>> package, we should have it at the source package level.
>
>> As such, I suggest that we handle "binary rebuild" differently:
>> - debian/changelog is left unmodified since it's the source changelog
>>   => it defines the ${source:Version} substvar
>> - debian/changelog.binary-rebuild (or any other better name) is created
>>   when we want to do a bin-nmu
>>   => it defines the ${binary:Version} and it's not included in
>>   the generated source package
>
> By definition a binNMU cannot produce a source package anyway, so I
> fail to see the point in this artifical need to distinguish “source”
> and “binary” changelogs through different files, AFAIR I already
> mentioned reasons against this in the ref-counting thread, and now
> again in reply to Ian's mail.

But if a binNMU changes debian/changelog then that change ends up in the
binary package. And that means you get a file collision for multiarch
where 2 packages contain the same file name but different contents.

So what is your solution there?

And no, moving the changelog to a -common deb does not solve the problem
since the binNMU would require a new -common deb while the original
wants the old one.

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

Re: Migration path for 'Multi-Arch:allowed' packages

[Goswin von Brederlow]

Andreas Barth  writes:

> * David Kalnischkies (kalnischk...@gmail.com) [120612 18:03]:
>> You need to upgrade to support MultiArch,
>> but you need MultiArch to upgrade…
>> (beside, how would the detection for such a message look like?)
>
> We had discussed to export foreign-arch packages to the arches
> packages files at debconf. That would mean in this case that the
> amd64-packages file contains the i386-package wine-bin. That would
> allow to detect we need multi-arch packages easily (and avoid that
> people have to add all i386-packages to an amd64-system just to
> install wine-bin).

Not at present. When parsing binary-amd64/Packages all Arch:i386 are
filtered out and not added to the database, not as long as multiarch is
not enabled.

> In order to get that going, we would need to document in the release
> notes that certain packages either need to be put on hold prior to
> the upgrade in case they're installed or to upgrade apt, aptitude and
> dpkg first. Both had been done before.

The prefered default should be to keep them on hold, leave them as they
are. But that probably won't work out for everyone. Documenting that
they should be held back is the best that can be done there I think.

But after a partial update maybe we could do better. Maybe we could add
a flag "X-Needs-Multiarch: " to the few packages that need it and
through that get apt-get/aptitude to generate a better error message
when the required foreign architecture is not configured?

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

Re: Bug#677230: ITP: adhcp -- DHCP implementation in Ada

[Adrian-Ken Rueegsegger]

Hi Steve,

On 06/12/2012 04:59 PM, Steve McIntyre wrote:
> On Tue, Jun 12, 2012 at 04:33:00PM +0200, Adrian-Ken Rueegsegger wrote:
[snip]
>> If it is the latter: I believe having a simple and robust DHCP
>> implementation would be beneficial for the Debian project in general.
> 
> How does Debian gain by including yet another implementation of a
> common low-level system networking tool, written in a rarely-used (in
> Debian) language? In fact, a tool that (according to your own upstream
> web page at http://www.codelabs.ch/adhcp/) hasn't even been formally
> released yet.

The intention is to coordinate the first official public release with
the Debian package so there are no differences between the upstream
release code and the one packaged in Debian.

I would like to add that Ada support in Debian is excellent thanks to
the efforts of Ludovic Brenta and the growing number of Ada enthusiasts.
There is also an offical Debian mailing list (added to CC), where
Ada-related topics are discussed.

> Apart from not being written in your language of choice, is there
> anything wrong with the existing implementations that would cause a
> Debian user to want to switch?

The decision to write a DHCP implementation from scratch was based on
the fact that the existing projects were not deemed to be robust
enough. The ADHCP implementation is designed to be simple and only
support essential features while still conforming to the related DHCP
RFCs. A small text file documenting the RFC compliance of ADHCP is part
of the project documentation.

Ada is a general purpose programming language, which helps design and
implement safe and reliable code. That's why Ada was the language of
choice for this project.

The software was developed for an IT-Security company and has been in
use for more than a year.

I think that ADHCP is of interest for users which want a minimal DHCP
implementation with a focus on robustness and reliability.

Regards,
Adrian


-- 
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/4fd86845.2020...@codelabs.ch

Bug#677341: ITP: librime -- Rime Input Method Engine, the core library

[Qijiang Fan]

Package: wnpp
Severity: wishlist
Owner: Qijiang Fan 

* Package name: librime
  Version : 0.9.1
  Upstream Author : GONG Chen 
* URL : http://code.google.com/p/rimeime
* License : GPLv3
  Programming Lang: C++
  Description : Rime Input Method Engine, the core library

RIME: Rime Input Method Engine

Features:

- lightweight, customizable and extensible framework
- supporting various input schemata including glyph-based input
methods, 
romanization-based input methods as well as those for Chinese
dialects
- syllabification algorithm adaptive to any scripting system
- intelligent composition of phrases and sentences
- accurate traditional Chinese output
- built on top of open-source technology
- cross-platform core library in C++
- OS-specific wrappers working consistently for Windows,
Linux and Mac OS



-- 
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/20120613103659.28782.52671.reportbug@fqj1994-laptop

Re: Migration path for 'Multi-Arch:allowed' packages

[Ben Hutchings]

On Tue, 2012-06-12 at 17:45 +0200, David Kalnischkies wrote:
> On Mon, Jun 11, 2012 at 9:40 PM, Michael Gilbert  wrote:
> > In particular, I filed a bug against dpkg requesting that it produce
> > more informative error messages in these cases [0], but I wonder if a
> > part of the solution shouldn't be more automated or at least presented
> > at a higher level through apt/aptitude, etc?
> 
> Chicken or the egg?
> 
> You need to upgrade to support MultiArch,
> but you need MultiArch to upgrade…
> (beside, how would the detection for such a message look like?)
[...]
> Maybe all maintainers who want to use Multi-Arch now in wheezy
> (and therefore drop amd64 packages) should get together and write
> a "what to do after the distribution upgrade" for the release notes,
> a (low priority) debconf message and if you want to be really fancy
> a "transitional" package which shows the same text in case the
> "dropped" binaries are executed.
[...]

I'd be interested in this for linux-image-amd64:i386.  Currently I
expect linux-image-3.2.0--amd64:i386 to remain in wheezy but we'll
still need to advise the user to enable amd64 ready for wheezy+1.  If we
can document multi-arch well enough in release notes etc. then it might
be possible to drop it now.

Ben.

-- 
Ben Hutchings
Computers are not intelligent.  They only think they are.


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

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

[Ben Hutchings]

On Wed, 2012-06-13 at 09:22 +0200, Bjørn Mork wrote:
> Serge  writes:
> 
> > Since tmpfs+swap is mostly slower than regular filesystem
> 
> And the world is flat.

Well... if you actually do have to swap, the I/O pattern is currently
not very efficient.  See .

Ben.

-- 
Ben Hutchings
Computers are not intelligent.  They only think they are.


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

Re: Summary: Moving /tmp to tmpfs makes it useless

[Ben Hutchings]

On Wed, 2012-06-13 at 09:22 +0200, Josselin Mouette wrote:
> Le mercredi 13 juin 2012 à 04:14 +0300, Serge a écrit : 
> > Yes. Everything. Every popular /tmp usage that most users expect to work
> > is limited either by CPU (gcc compiling) or by network speed (browser or
> > flash temporaries), or is just too fast already (bash heredoc). So moving
> > /tmp to tmpfs does not make them faster, but can break them instead (if
> > there's not enough space to store a streamed video, for example).
> 
> You should really back up claims such as “GCC is CPU-bound” with data.
> 
> Because it sounds to me that when building with make -j8 on a fast
> multi-core system, you will hit the IOPS limit of a rotating drive very
> quickly.
[...]

It's fine with a local disk and enough RAM for a decent disk cache.
(NFS is another matter.)

Ben.

-- 
Ben Hutchings
Computers are not intelligent.  They only think they are.


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

Re: DEP-8 extension proposal: Add source package header

[Stuart Prescott]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi Martin,

The contents of all source packages is already available in 
Contents-source.gz on your favourite mirror [1]. That means you can:

$ apt-file -a source update
…
$ apt-file -a source -l search debian/tests/control
apipkg
bobo
bzr
bzr-email
bzr-fastimport
bzr-git
…
$ apt-file -a source -l search debian/tests/control | wc -l
66

Maybe this is an easier option than adding yet another new field 
and patching tools to generate it.

cheers
Stuart

[1] wheezy, sid, experimental (not older releases),
http://cdn.debian.net/debian/dists/sid/main/Contents-source.gz


- -- 
Stuart Prescott www.nanoNANOnano.net
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)

iEYEARECAAYFAk/Ye/oACgkQn+i4zXHF0ai1hQCguRLGOfvM1BrOKlhAcH8YsPtw
ZmsAn0gjtAi1YRF03VyT/yYgBoxLbjvT
=Hwvn
-END PGP SIGNATURE-



-- 
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/jr9u63$nju$1...@dough.gmane.org

Re: Migration path for 'Multi-Arch:allowed' packages

[Wookey]

+++ Ben Hutchings [2012-06-13 12:24 +0100]:
> On Tue, 2012-06-12 at 17:45 +0200, David Kalnischkies wrote:
> > On Mon, Jun 11, 2012 at 9:40 PM, Michael Gilbert  
> > wrote:
> > > In particular, I filed a bug against dpkg requesting that it produce
> > > more informative error messages in these cases [0], but I wonder if a
> > > part of the solution shouldn't be more automated or at least presented
> > > at a higher level through apt/aptitude, etc?
> > 
> > Chicken or the egg?
> > 
> > You need to upgrade to support MultiArch,
> > but you need MultiArch to upgrade…
> > (beside, how would the detection for such a message look like?)
> [...]
> > Maybe all maintainers who want to use Multi-Arch now in wheezy
> > (and therefore drop amd64 packages) should get together and write
> > a "what to do after the distribution upgrade" for the release notes,
> > a (low priority) debconf message and if you want to be really fancy
> > a "transitional" package which shows the same text in case the
> > "dropped" binaries are executed.
> [...]
> 
> I'd be interested in this for linux-image-amd64:i386.  Currently I
> expect linux-image-3.2.0--amd64:i386 to remain in wheezy but we'll
> still need to advise the user to enable amd64 ready for wheezy+1.  If we
> can document multi-arch well enough in release notes etc. then it might
> be possible to drop it now.

I added a user-oriented HOWTO to the multiarch doc-collection last
month as there seemed to be a shortage of such docs to point to that
weren't cryptic specifications, or talking mostly about
cross-building. It may be a useful place to point people, or just lift
the good bits from it:

http://wiki.debian.org/Multiarch/HOWTO

Wookey
-- 
Principal hats:  Linaro, Emdebian, Wookware, Balloonboard, ARM
http://wookware.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/20120613114727.gp13...@stoneboat.aleph1.co.uk

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

[Henrique de Moraes Holschuh]

On Wed, 13 Jun 2012, Ben Hutchings wrote:
> On Wed, 2012-06-13 at 09:22 +0200, Bjørn Mork wrote:
> > > Since tmpfs+swap is mostly slower than regular filesystem
> > 
> > And the world is flat.
> 
> Well... if you actually do have to swap, the I/O pattern is currently
> not very efficient.  See .

Yes, and fixing that for good would give us an entirely new world of
benefits.  But it is also a damn hard problem, or it'd have been fixed a
long time ago...

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh


-- 
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/20120613123921.gb26...@khazad-dum.debian.net

Re: Is it me or virtualbox memory management crap?

[Thomas Goirand]

On 06/11/2012 06:46 AM, Serge wrote:
> Do you use 2.6 kernel and have FF profile and VB images on the same ext4
> partition?
>   

My laptop setup is:
- kernel 2.6.32-5 (Squeeze...)
- RAID1 (replacing my thinkpad DVD ultrabay by a 2nd HDD)
- LVM
- dm-crypt
- ext3

Yes, both the VB images and FF profile are on the same partition,
as I want both to be encrypted. Writing to my disk is normally quite
fast, but I've noticed indeed that when it's VB that does it, it's slow.
If I don't find a way, I guess I'll switch back to Xen with NAT...

> Can you reproduce that with 3.2 kernel?
>   

Why would this change?

> PS: you can check the output of `latencytop` as well
zigo@buzig ~$ sudo latencytop
Please enable the CONFIG_LATENCYTOP configuration in your kernel.
Exiting...

Is there a kernel module to load? Or is this only available in 3.2?

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/4fd88bab.40...@debian.org

tmpreaper maintainership

[Henrique de Moraes Holschuh]

> > - There's no danger of a symlink attack or similar with things like
> >   tmpreaper -- or indeed any need for tmpreaper anymore. You reboot the
> >   system, and /tmp is clean again, no matter what was there before. This
> >   is more than just a convenience.

We really ought to fix tmpreaper then, it can be very dangerous to have any
race conditions in it.

At first glance, it looks like tmpreaper needs a resync it with its upstream
to pick up any bug fixes (https://fedorahosted.org/tmpwatch/).  Is there any
good reason to package a fork instead of working with upstream to merge any
functionality introduced in tmpreaper?

Paul?  What should be the fate of tmpreaper?  If you're not maintaining it
anymore, can you orphan it at least to make that clear?

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh


-- 
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/20120613125137.gc26...@khazad-dum.debian.net

Bug#677372: ITP: libparse-edid-perl -- Extended display identification data (EDID) parser

[Gonéri Le Bouder]

Package: wnpp
Severity: wishlist
Owner: "Gonéri Le Bouder" 

* Package name: libparse-edid-perl
  Version : 1.0 
  Upstream Author : Pascal Rigaux, Mandriva, Anssi Hannula, Guillaume Rousse
* URL : https://metacpan.org/release/Parse-EDID
* License : GPLv3+
  Programming Lang: Perl
  Description : Extended display identification data (EDID) parser

This module provides some function to parse Extended Display Identification
Data binary data structures.



-- 
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/20120613125203.18878.40279.reportbug@localhost

Re: Is it me or virtualbox memory management crap?

[Simon McVittie]

On 13/06/12 13:46, Thomas Goirand wrote:
> Writing to my disk is normally quite
> fast, but I've noticed indeed that when it's VB that does it, it's slow.
> If I don't find a way, I guess I'll switch back to Xen with NAT...

No opinion on VirtualBox, Xen or performance thereof, but kvm is also an
option. I sometimes run virtual machines for development, on a laptop
with ext3 over LVM over dm-crypt (so the complete stack from VM to disk
is: ext3, qcow2, ext3, LVM, dm-crypt, disk) and I've had acceptable
performance. I use virt-manager to simplify dealing with the VMs.

S


-- 
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/4fd89230.9020...@debian.org

Bug#677388: ITP: pinentry-x2go -- GnuPG-card authentication dialog window for X2Go Client

[Mike Gabriel]

Package: wnpp
Severity: wishlist
Owner: Mike Gabriel 

* Package name: pinentry-x2go
  Version : 0.7.5.2
  Upstream Author : Oleksandr Schneyder
* URL : http://wiki.x2go.org
* License : GPL-2+
  Programming Lang: C++
  Description : GnuPG-card authentication dialog window for X2Go Client

X2Go is a serverbased computing environment with
- session resuming
- low bandwith support
- LDAP support
- client side mass storage mounting support
- audio support
- authentication by smartcard and USB stick

This packages contains an X2Go Client add-on. The add-on provides a PIN or
passphrase dialog window for GnuPG card authentication with X2Go.



-- 
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/20120613141039.32662.17756.report...@minobo.das-netzwerkteam.de

Re: Is it me or virtualbox memory management crap?

[Thomas Goirand]

On 06/13/2012 09:14 PM, Simon McVittie wrote:
> On 13/06/12 13:46, Thomas Goirand wrote:
>   
>> Writing to my disk is normally quite
>> fast, but I've noticed indeed that when it's VB that does it, it's slow.
>> If I don't find a way, I guess I'll switch back to Xen with NAT...
>> 
> No opinion on VirtualBox, Xen or performance thereof, but kvm is also an
> option. I sometimes run virtual machines for development, on a laptop
> with ext3 over LVM over dm-crypt (so the complete stack from VM to disk
> is: ext3, qcow2, ext3, LVM, dm-crypt, disk) and I've had acceptable
> performance. I use virt-manager to simplify dealing with the VMs.
>
> S
>   

VirtualBox is only nice because of its GUI. Otherwise, KVM or XEN
outperforms it a lot, especially on I/O. Also, VB is convenient because
of its bridging thing which works even on WiFi. Unless I'm mistaking,
Xen can't do bridging on WiFi (I'd be *very* happy to be wrong here,
so if I am, please let me know!), and NAT is always annoying me,
which is why I continue with VB for my SID VM.

Anyway, thanks for the hint, I may give (another) try with KVM. Is there
any good GUI that I could use for it (that would work in Squeeze)? Does
it performs a lot faster if I give it a full LVM partition as HDD, or I wont
see much difference with qcow2? I mainly know Xen a lot, and (a bit less)
KVM on the command line, but it'd be nice to use a GTK/Qt GUI too.

Thomas

P.S: Sorry for the noise to those who don't care, I quite know it's a bit
OT for -devel, but it would really improve my work to have better VM tools.


-- 
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/4fd8ae8b.4000...@debian.org

Maintainers, teams, Uploaders, DMs, DDs, etc.

[Ian Jackson]

It's evident from recent conversations in various places that we are
confused about:
 - what Maintainer and Uploaders mean
 - who is entitled to do what when
 - in some cases, the distinction between ability and permission
etc.


I'm going to try to set out my understanding of the current best
practices, with some open questions and suggestions for improvement.
I'm proposing this as an alternative to the existing plan to change
the way DM permission works.

But firstly I want to explain an important principle: the distinction
between ability and permission.  In any complex collective endeavour,
there will be both access controls that actually prevent some people
from taking certain acts, and ideas (whether stated formally and
clearly, or informally and vaguely) about what should be done when and
by whom.

Access restrictions are annoying to implement and work with so they
should be minimised where possible - but they are a necessary backstop
to prevent abuse.  In general access restrictions need to be flexible
enough that it is possible to revoke the permissions of someone who is
using their technical ability in ways that are considered undesirable
by whoever is supposed to be in charge.  But, provided that there are
sufficient facilities for reverting misdeeds and mistakes, they do not
need to be more complex than that.

So for example, DDs have enormous theoretical power but there are
strong and well documented social controls on how they should exercise
that.  I think as a matter of principle that the same principle should
apply to DMs: it is easy to remove a misbehaving DM from Uploaders.
So it is not necessary to have technical measures that prevent a DM
mentioned in Uploaders from violating the package's uploading rules,
bypassing review processes, or whatever.  Instead, when a package team
or lead maintainer accepts someone into Uploaders we should clearly
communicate to the new uploader what is expected of them, and then we
should trust them to do as we have asked.


So firstly, let me go through the actual places where we as a project
store information about the maintenance structure of a package:

 * Maintainer field
 * Uploaders field
 * DM-Upload-Allowed field
 * The DD keyring
 * The DM keyring
 * Team membership lists kept elsewhere (eg, a team webpage or
   wiki page, mailing list membership, or whatever)
 * Team practices/processes/policy agreements, documents, etc.
   (which might include anything from informal private emails to
   formal process and governance documents)


The questions that need to be answered for a package are:

 * Who is (supposedly) doing most of the work.

 * Who makes final decisions about the package; this includes
   arbitraring disputes, delegating authority, revoking such
   delegation, etc.

   The identity of the people with this responsibility needs to be
   accessible to the project as a whole so that people who are
   unfamiliar with the package can see whose opinions are definitive.
   This information does not normally need to be used automatically by
   the project's support infrastructure.

   I'm going to call these people the maintainers of the package.
   They might be DDs, DMs, or contributors without a key in the
   keyring.

   Currently this information is sometimes in the Maintainer field;
   sometimes in both the Uploaders and Maintainers fields; and
   sometimes somewhere else completely (eg a team wiki page).

   Normally the maintainers would be the people who are doing most of
   the work.  Sometimes we have provisional maintainers who are
   neither DD or DM; in those cases the maintainer works under the
   supervision of their sponsors.

c. Who is entitled to prepare a non-NMU upload of the package.

   This information needs to be accessible to the project as a whole.

   Particularly a potential drive-by sponsor needs to know whether the
   upload they are sponsoring is by someone entitled to prepare such
   an upload.  And the archive software needs to know whether to
   permit an upload.

   Currently this information is sometimes in the Maintainer field;
   sometimes in both the Uploaders and Maintainers fields; and
   sometimes somewhere else completely (eg a team wiki page).

d. Who is morally entitled to perform various other actions with
   respect to the package, such as manipulating bugs, committing to
   its vcs, etc.

   This information does not need to be available to people outside
   the team involved with the package.  If disputes arise they can be
   dealt with by the maintainers, and if necessary the maintainers can
   invoke various enforcement mechanisms to stop misbheaviour.

e. What process should someone preparing a non-NMU upload follow?

   Eg, is there a VCS that everything should be committed to ?  Are
   non-emergency uploads supposed to be reviewed somewhere ?  Are some
   of the people who are entitled to upload supposed only to do so
   after explicit indication by someone more senior that they should
   d

Re: Is it me or virtualbox memory management crap?

[Ben Hutchings]

On Wed, Jun 13, 2012 at 11:15:23PM +0800, Thomas Goirand wrote:
> On 06/13/2012 09:14 PM, Simon McVittie wrote:
> > On 13/06/12 13:46, Thomas Goirand wrote:
> >   
> >> Writing to my disk is normally quite
> >> fast, but I've noticed indeed that when it's VB that does it, it's slow.
> >> If I don't find a way, I guess I'll switch back to Xen with NAT...
> >> 
> > No opinion on VirtualBox, Xen or performance thereof, but kvm is also an
> > option. I sometimes run virtual machines for development, on a laptop
> > with ext3 over LVM over dm-crypt (so the complete stack from VM to disk
> > is: ext3, qcow2, ext3, LVM, dm-crypt, disk) and I've had acceptable
> > performance. I use virt-manager to simplify dealing with the VMs.
> >
> > S
> >   
> 
> VirtualBox is only nice because of its GUI.

Can't say I've ever tried running it, but VirtualBox kernel modules
are considered too bad even for staging and are the primary reason for
the recently added 'O' taint bit.

> Otherwise, KVM or XEN
> outperforms it a lot, especially on I/O. Also, VB is convenient because
> of its bridging thing which works even on WiFi. Unless I'm mistaking,
> Xen can't do bridging on WiFi (I'd be *very* happy to be wrong here,
> so if I am, please let me know!), and NAT is always annoying me,
> which is why I continue with VB for my SID VM.
> 
> Anyway, thanks for the hint, I may give (another) try with KVM. Is there
> any good GUI that I could use for it (that would work in Squeeze)?
[...]

I think there is a usable version of virt-manager in squeeze.

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/20120613160411.gi2...@decadent.org.uk

Re: Please consider stopping uploads with *uncoordinated* changes to debconf templates before the release

[Axel Beckert]

Dear Christian,

Christian PERRIER wrote:
> I would hereby kindly ask to consider [...] I am considering to ask
> our release team to *block* transitions for such packages with
> uncoordinated debconf changes, on a case by case basis.

JFTR: Menacing is _neither_ "kindly asking" nor does it leave an
option "to consider".

> During last weeks, several package maintainers did such changes
> (ledgersmb, icinga, pleiades, uptimed, nginx, nova and, last but not
> least, screen).

Since you mention one of my packages explicitly, I have to object:

On http://people.debian.org/~jfs/debconf6/html/x59.html#AEN86 there is
written:

| I18N & L10N FAQ for maintainers
|
| How do I get a given text translated?
|
| For translate package description or debconf templates, you have do
| not need to do anything at all. The DDTP infrastructure will send
| the translatable descriptions volunteers, and process the resulting
| translations with no need for you to interact. Addition of debconf
| templates is followed by translation teams that will send you new
| translations for them through the Bug Tracking System (you can
| contact debian-i18n, however, if you would like translations before
| releasing a new package version).

That's exactly what I did (and planned to do) and it sounds perfectly
sane to me.

You are (co-) author of that document and it is referred to in the
developer's reference in the "Best packaging practices" section at
http://www.debian.org/doc/manuals/developers-reference/best-pkging-practices.html#bpp-i18n

And this is the first answered question in the FAQ and hence obviously
the most important one, otherwise it wouldn't come first, would it?

And yes, there are further answers in that FAQ.

But how should I know when reading this that I _must_ _not_ follow the
advice cited above and that the things in the very last question(*) of
that FAQ are not as optional as the first two words of the answer
("You can") suggest?

(*) Who reads an FAQ further if the first answer perfectly answers
what you want to know?

IMHO things would generally go smoother and with far less angryness on
both sides if such mails would be less reproachful and less menacing.

E.g. your bug report at http://bugs.debian.org/677303 was a good and
friendly start to introduce me into the non-trivial translation
workflow of debconf templates.

But your not so friendly mail to -devel et al. (cited above) destroyed
quite a lot of my willingness to invest time in finding out what
exactly I'm supposed to do with regards to debconf translations --
also because I had to waste quite some time to protest and defend
myself against your allegations (i.e. to write this mail) -- hopefully
without starting the next flame-war.

Going now back to continue my packaging work (including some i18n
stuff) and fixing RC bugs. Thanks for list^Wreading.

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , http://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE
  `-|  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5


-- 
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/20120613162636.gg3...@sym.noone.org

Re: Maintainers, teams, Uploaders, DMs, DDs, etc.

[Bernhard R. Link]

* Ian Jackson  [120613 17:35]:
> 5. Introduce a new conventional location for information useful to
>NMUers,
>   debian/README.nmu
>
>Explicitly state that someone preparing or sponsoring an NMU should
>consult this file.  Statements in this file may supplement, but do
>not overrule, the NMU criteria established by the Developers'
>Reference, by the release team, or elsewhere.
>
>Explicitly state that NMUers are NOT necessarily required to
>consult README.maintain.

Adding something for NMUs in the package without adding some way to
give more information for NMUs outside the package might result in
information getting in there that will usually be outdated when an NMU
is needed. (after all, NMUs are especially common when noone else did
an upload for a longer time, so a upload just to get that file within
the package is also unlikely to have happened).

Bernhard R. Link


-- 
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/20120613163535.ga30...@client.brlink.eu

Re: Maintainers, teams, Uploaders, DMs, DDs, etc.

[Arno Töll]

Hi,

first: thank you. Recent threads show, we clearly need a discussion like
this and hopefully people will take it as an opportunity to leave this
thread a bit more enlightened.

On 13.06.2012 17:35, Ian Jackson wrote:
>Instead, when a package team
> or lead maintainer accepts someone into Uploaders we should clearly
> communicate to the new uploader what is expected of them, and then we
> should trust them to do as we have asked.

A DM can't upload anything, just because of his being as a DM. It's the
uploader field AND the DMUA flag which matters. So, if you don't trust a
person to upload packages, don't set the flag.

Since that's per package and not per person and package, this might have
some side effects, but Ansgar is about to change that, so we do not need
to worry too much about that (again).

> c. Who is entitled to prepare a non-NMU upload of the package.
> 
>Particularly a potential drive-by sponsor needs to know whether the
>upload they are sponsoring is by someone entitled to prepare such
>an upload.  And the archive software needs to know whether to
>permit an upload.

By the way, for a sponsored maintainer there is no trusted evidence at
all whether you are sponsoring an upload of said person or of an impostor.

Drive-by sponsoring makes this even more complicated and is not helping
anybody. We should stop advocating drive-by sponsoring at all.

1) You upload a package without feeling responsible for it over a longer
term. Thus, that package is virtually stuck forever as is in Debian
because ...
2) ... Drive-by sponsoring does not work. It's annoying and
back-breaking to the sponsored maintainer to have a package containing
lots of fixes and maybe a new upstream version but nobody which uploads
the you've been working on (yes, that happens)
3) It's not helpful because the sponsor, at best, has a rough and
cursory understanding how the package works.
4) It's not clear at all how a bug fix could be uploaded to Debian at
all, so the package might be in bad shape soon as nobody who /could/
upload feels responsible for it and those who care /can't/ upload.

> f. Are there specific things that an NMUer should watch out for ?
> 
>Currently we have no general way of finding these.  The closes is
>the LowThresholdNmu wiki page.

There clearly are. Just read
  http://www.debian.org/doc/manuals/developers-reference/pkgs.html#nmu

And hopefully some other people regularly sponsoring or doing themselves
unacceptable NMUs do so as well.

>  * Individual DD or DM maintainer, perhaps with co-maintainers.  The
>single individual principal maintainer is listed in Maintainer and
>makes all decisions.  Co-maintainers are listed in Uploaders and
>may make their own uploads and may in general make decisions where
>not contradicted by the principal maintainer.  There may or may not
>be any information for NMUers.

I do not like that idea of introducing more and less important people
and classes for a package. That's against our spirit. However, as I said
in IRC: De-facto that's the case for a long time already, so be it for
the sake of just stopping to trick ourselves here.

I think that part of your suggestion is improvable, though. After all I
do not think there is (should be) any difference in authority at all -
whether someone is listed as a maintainer or as a uploader does not
matter to me. The rationale for the Uploader field is a technical one
and has nothing to do with actual powers. It clearly should have been
named different, however.


> 1. Change the definition of the Maintainer field to permit multiple
>entries.

There were probably technical reasons back then when introducing
Uploaders. Maybe someone knows.

> 2. Explicitly state that being listed in Uploaders does not in itself
>imply general authority over the package; general authority is
>reserved to maintainers.

That would be a sad day for Debian as a whole because it introduces a
class society within Debian. But again, de-facto that's a truth already.

> 3. Introduce a new conventional location for information about a
>maintenance team and a package's maintenance practices,
>   debian/README.maintain
>in the source package.

That's a good idea I like.

> 5. Introduce a new conventional location for information useful to
>NMUers,
>   debian/README.nmu

Likewise.

Maybe we could stick both, the maintainer and the NMU information
README.source though, as people suggested in IRC.

> It doesn't seem to me that there is any need to change the archive
> machinery to handle DM permissions differently.

There are lots of reason if you look into the dak source and check how
exactly DM upload permissions are hacked into it.


-- 
with kind regards,
Arno Töll
IRC: daemonkeeper on Freenode/OFTC
GnuPG Key-ID: 0x9D80F36D



signature.asc
Description: OpenPGP digital signature

Re: Maintainers, teams, Uploaders, DMs, DDs, etc.

[Gergely Nagy]

Ian Jackson  writes:

> So for example, DDs have enormous theoretical power but there are
> strong and well documented social controls on how they should exercise
> that.  I think as a matter of principle that the same principle should
> apply to DMs: it is easy to remove a misbehaving DM from Uploaders.

For some values of easy. It requires a sourceful upload for possibly no
other reason than to remove an uploader. That's a waste of time, not
only for the maintainers, but the buildds and archive software too.

Would the package take long to compile, it would be even worse.

We can't compare this to the case of DD's, because DD upload rights are
only governed by social customs and the keyring, the DMs have
*additional* restrictions, which currently are tied to the source
package.

> So it is not necessary to have technical measures that prevent a DM
> mentioned in Uploaders from violating the package's uploading rules,
> bypassing review processes, or whatever.  Instead, when a package team
> or lead maintainer accepts someone into Uploaders we should clearly
> communicate to the new uploader what is expected of them, and then we
> should trust them to do as we have asked.

Well, one of the reasons DMs are not DDs, is because they do not have
the same rights as DDs do: they can't, and in my opinion, shouldn't be
able to upload pretty much any package without further restrictions. If
they would, they'd technically have the same upload rights as DDs do,
with a fraction of the experience, and without going through NM. I don't
think that would be wise. (No disprespect meant for DMs, mind you)

However, this (whether we need the extra upload restrictions for DMs), I
believe is not strictly related to the proposal, which, to my reading,
was more about moving the DM-Allowed field out of the source package,
and a few other things.

> The questions that need to be answered for a package are:
[..]
>  * Who makes final decisions about the package; this includes
>arbitraring disputes, delegating authority, revoking such
>delegation, etc.
[...]
>I'm going to call these people the maintainers of the package.
>They might be DDs, DMs, or contributors without a key in the
>keyring.
>
>Currently this information is sometimes in the Maintainer field;
>sometimes in both the Uploaders and Maintainers fields; and
>sometimes somewhere else completely (eg a team wiki page).
>
>Normally the maintainers would be the people who are doing most of
>the work.  Sometimes we have provisional maintainers who are
>neither DD or DM; in those cases the maintainer works under the
>supervision of their sponsors.

So far, I agree.

> c. Who is entitled to prepare a non-NMU upload of the package.
>
>This information needs to be accessible to the project as a whole.
>
>Particularly a potential drive-by sponsor needs to know whether the
>upload they are sponsoring is by someone entitled to prepare such
>an upload.  And the archive software needs to know whether to
>permit an upload.
>
>Currently this information is sometimes in the Maintainer field;
>sometimes in both the Uploaders and Maintainers fields; and
>sometimes somewhere else completely (eg a team wiki page).

There's also the case of DM-Allowed: yes. If someone is listed as
maintainer, but is not a DD, then my understanding is, that he is not
entitled to upload. (Hence, should not be in Uploaders, either, unless
DM-Allowed: yes is set)

This looks silly, though, and inconsistent, and very easy to miss when
sponsoring or working within a larger team.

Nevertheless, in case the maintainer is not a DD, he either needs a
sponsor, or must be a DM, with the package having DM-Allowed: yes. This
also presents a problem when adopting packages, because if the adopter
is a DM, someone must sponsor his first upload or set DM-Allowed: yes
otherwise in a separate upload - neither of which is particularly
friendly towards the DM (nor anyone else, really).

Would this restriction get untied from the source, the former maintainer
could grant upload rights without having to do a sourceful upload, and
everyone wins, and no rights get harmed either.

> e. What process should someone preparing a non-NMU upload follow?
>
>Eg, is there a VCS that everything should be committed to ?  Are
>non-emergency uploads supposed to be reviewed somewhere ?  Are some
>of the people who are entitled to upload supposed only to do so
>after explicit indication by someone more senior that they should
>do so ?
>
>Again this information doesn't generally need to be available to
>people outside the packaging team.  However, if there are
>significant and important processes that should be followed, a
>drive-by sponsor should be able to find them easily so that they
>can double-check that the person preparing the upload (the sponsee)
>seems to be doing the right thing.
>
>Currently this information is, if 

Re: Maintainers, teams, Uploaders, DMs, DDs, etc.

[Arno Töll]

Hi,

as a clarification, because I was pointed to it:

On 13.06.2012 18:54, Arno Töll wrote:
> Drive-by sponsoring makes this even more complicated and is not helping
> anybody. We should stop advocating drive-by sponsoring at all.

... with the exception of evident cases like RC bug fixes, emergency
uploads or any other kind of upload where an urgent fix is needed.

That's clearly not what I meant to address. I am merely addressing the
phenomenon of mass drive-by sponsoring of random packages.

Yes, that happens quite regularly and I do not think this is how
sponsoring should work at all.


-- 
with kind regards,
Arno Töll
IRC: daemonkeeper on Freenode/OFTC
GnuPG Key-ID: 0x9D80F36D



signature.asc
Description: OpenPGP digital signature

Re: Maintainers, teams, Uploaders, DMs, DDs, etc.

[Michael Gilbert]

On Wed, Jun 13, 2012 at 1:35 PM, Arno Töll wrote:
> Hi,
>
> as a clarification, because I was pointed to it:
>
> On 13.06.2012 18:54, Arno Töll wrote:
>> Drive-by sponsoring makes this even more complicated and is not helping
>> anybody. We should stop advocating drive-by sponsoring at all.
>
> ... with the exception of evident cases like RC bug fixes, emergency
> uploads or any other kind of upload where an urgent fix is needed.
>
> That's clearly not what I meant to address. I am merely addressing the
> phenomenon of mass drive-by sponsoring of random packages.
>
> Yes, that happens quite regularly and I do not think this is how
> sponsoring should work at all.

Is that worse than the package being completely ignored?

I'm really not sure what your definition of drive-by is.  Sometimes
I'll make time to look at a package interesting me, I'll communicate
with the sponsoree, upload it if they address my concerns, then follow
it for a little while to make sure nothing bad happened.  Is that a
drive-by?

Best wishes,
Mike


--
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/CANTw=mpor0iogzapdsltdjhhq8v6bywgnsg4p4pzeqkhfdd...@mail.gmail.com

Re: Maintainers, teams, Uploaders, DMs, DDs, etc.

[Arno Töll]

Hi,

On 13.06.2012 19:46, Michael Gilbert wrote:
> I'm really not sure what your definition of drive-by is.  Sometimes
> I'll make time to look at a package interesting me, I'll communicate
> with the sponsoree, upload it if they address my concerns, then follow
> it for a little while to make sure nothing bad happened.  Is that a
> drive-by?

It's a drive-by upload if you disappear thereafter and you are not
replying to you sponsored maintainer's mails asking you for a follow-up
upload.

You are just describing how many (most?) sponsorship relations start and
that's perfectly fine. It's what happens (or rather: what's not
happening) afterwards which worries me in some cases.

-- 
with kind regards,
Arno Töll
IRC: daemonkeeper on Freenode/OFTC
GnuPG Key-ID: 0x9D80F36D



signature.asc
Description: OpenPGP digital signature

Bug#677415: ITP: clustersync -- Tool for replicating and syncing config files

[Arturo Borrero Gonzalez]

Package: wnpp
Severity: wishlist
Owner: Arturo Borrero Gonzalez 

* Package name: clustersync
  Version : 0.4
  Upstream Author : Arturo Borrero Gonzalez 
* URL : https://github.com/aborero/clustersync
* License : GPL
  Programming Lang: Bash
  Description : Tool for replicating and syncing config files

 This is a tool based on Rsync that helps syncing and replicating
 config files and other data between nodes of a cluster, where you
 expect to have the same configuration in several machines.



-- 
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/20120613202713.6321.58686.reportbug@nostromo

Re: Maintainers, teams, Uploaders, DMs, DDs, etc.

[Ansgar Burchardt]

Hi,

Ian Jackson  writes:
> I think the first three can be fixed relatively simply.  I propose the
> following changes:
>
> 1. Change the definition of the Maintainer field to permit multiple
>entries.
>
>There are currently four different entities (3 humans and a
>corporation) which use a comma in a Maintainer field, in only 13
>different source packages.  None of these commas are essential to
>comprehension (indeed in principle those same entities might have
>to have variants of their identification without commas, suitable
>for use in Uploaders).  All but one of these Maintainer fields are
>already violations of policy 5.6.2 which says that the Maintainer
>field must be in "RFC822 format" (a bit vague, but clearly excludes
>bare commas).
>
>So this is an easy change.

This was suggested when the Uploaders field was originally introduced,
but not done in order to avoid breaking tools that rely on having only
one entry in the Maintainer field[1].

  [1] 

I find it also interesting to note that Uploaders was originally called
Maintainers in said bug report.

> 2. Explicitly state that being listed in Uploaders does not in itself
>imply general authority over the package; general authority is
>reserved to maintainers.

I disagree with this quite strongly: while it may be current practice
that some maintainers have more to say about a particular package than
other maintainers, this is currently part of the *private* relation
between maintainers.  To outsiders they can (and should!) still be
peers.

Your suggested change would instead formally introduce 2nd class
maintainers which I would not like to endorse.  I do not think I would
have felt as welcome in Debian as I did if this had been the case.

> 3. Introduce a new conventional location for information about a
>maintenance team and a package's maintenance practices,
>   debian/README.maintain
>in the source package.
>
[...]
>
> 5. Introduce a new conventional location for information useful to
>NMUers,
>   debian/README.nmu

I think this information could be located in README.source just as
well.

> It doesn't seem to me that there is any need to change the archive
> machinery to handle DM permissions differently.

I am still not sure what you find so bad about the proposed changes.
But let's go through all changes to try and keep everyone happy:

a, Drop the requirement that DMs cannot sponsor packages they can upload
   themselves.

b, Identify DMs by fingerprint instead of name/mail. This is how dak
   sees everyone else and avoids problems with multiple uids (as dak
   only knows about one of them).

c, Move the DM-U-A flag to projectb instead of the source package. Also
   use an explicit list for upload permissions instead of having it
   implied by Maintainer/Uploaders (which we need anyway as we want to
   use fingerprints).

d, Allow *only* DDs to change upload permissions.

   This is unrelated to the other changes.  We could technically allow
   DMs that have upload privileges for a package to grant that to others
   as well, but I do not believe this to be intended by the DM concept.

None of these changes are intended to take anything away from DMs which
I get the impression you believe.  a, and b, certainly don't as we drop
some restrictions currently implemented in dak.  c, is mostly a change
how DM is implemented; it also allows a DD to grant upload permissions
to multiple packages at once when he is convinced the DM can handle
them (eg. a group of similar or closely related packages).

I also don't believe d, should be a large problem for DMs in
practice.  They should already know a DD they can ask to set DM-U-A for
them just as they would need for a package where the other maintainer
was not already a DM.

In fact your proposed changes might be more restrictive to both DMs and
non-D[DM] maintainers as it makes it harder for them to find sponsors
when they are "only" listed in Uploaders.  We already don't have enough
people mentoring others and I doubt having them check additional things
(May an Uploader change source format for this package? May he switch
packaging tools? ...) would bring improvements.

Regards,
Ansgar


-- 
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/87ehpigazs@deep-thought.43-1.org

Bug#677425: ITP: xserver-xorg-video-modesetting -- X.Org X server -- Generic modesetting driver

[Cyril Brulebois]

Package: wnpp
Severity: wishlist
Owner: Cyril Brulebois 

* Package name: xserver-xorg-video-modesetting
  Version : 0.3.0
  Upstream Author : Tungsten Graphics, Dave Airlie, Red Hat…
* URL : 
http://cgit.freedesktop.org/xorg/driver/xf86-video-modesetting/
* License : MIT/X
  Programming Lang: C
  Description : X.Org X server -- Generic modesetting driver

Long description:
---
 This package provides a generic modesetting driver.
 .
 More information about X.Org can be found at:
 http://www.X.org>
 .
 This package is built from the X.org xf86-video-modesetting driver module.
---

The package is ready (thanks, Timo!), waiting for an ITP number.

Mraw,
KiBi.



-- 
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/20120613212319.15892.49747.report...@kashyyyk.rennes.ariadnext.com

Re: DEP-8 extension proposal: Add source package header

[Stefano Zacchiroli]

[ Adding autopkgtest-devel to recipients, where I've also just bounced
  your mail. If you're interested in this topic, please consider
  subscribing to that, very low traffic, list. ]

On Wed, Jun 13, 2012 at 09:44:46AM +0200, Martin Pitt wrote:
> in Ubuntu we have started adding some autopkgtests to packages, using
> the DEP-8 debian/tests/control standard [1]. We now also have a test
> execution environment [2] which automatically triggers autopkgtest
> runs for a package and all its reverse dependencies on each upload.

Oh, that's nice, thanks! Is the test execution environment something
that can easily deployed elsewhere? While autopkgtest itself (the
package) has received attention in Debian, we haven't yet managed to
restart test executions. I'm happy to consider alternatives if they're
more readily available for deployment than existing alternatives.

I'm also curious about the implementation: do you actually use
autopkgtest as low level test runner for Jenkins integration or...?

> The main problem that we are facing with this is that it is not easily
> discoverable which source packages actually ship tests. Right now this
> is a hardcoded list, which does not scale at all. Thus I would like to
> propose to add a source package header, so that test execution
> environments can find out packages with tests by merely scanning
> Sources.gz (or iterating over the package dict with python-apt and the
> like).
> 
> What do you think about something like this? (Diff against [3])

As a temporary alternative to a hardcoded list, Stuart's proposal to use
Contents-source.gz is clearly better.

But as a long term solution I like source metadata, as you propose,
more. It is more independent from the source package layout and it makes
it trivial to access the metadata via APT, as you point out. More
profoundly, I'm inclined to consider testsuite information as first
class source metadata, no less than other similar metadata like the
Vcs-* fields. The space bloat problem seems negligible in this case,
especially considering we're talking about Sources rather than Packages.

As long as it stays as a XS-* header (which, for the history, it's also
how Vcs-* fields came into existence), no tool change is needed. We
should just agree upon a name. But if we want to have hopes to promote
it to something more official, I think it should rather be independent
from autopkgtest. How about something like "XS-Testsuite: runtime",
where the key is actually a space separate list of values values.  Right
now only "runtime" [1] makes sense, but others might appear in the
future.

Cheers.


[1] or maybe "autopkgtest" if we want to be specific about the
testrunner, but that doesn't seem to be a god idea
-- 
Stefano Zacchiroli zack@{upsilon.cc,pps.jussieu.fr,debian.org} . o .
Maître de conférences ..  http://upsilon.cc/zack ..  . . o
Debian Project Leader ...  @zack on identi.ca ...  o o o « the
first rule of tautology club is the first rule of tautology club »


signature.asc
Description: Digital signature

Re: Maintainers, teams, Uploaders, DMs, DDs, etc.

[Charles Plessy]

Le Wed, Jun 13, 2012 at 06:47:32PM +0200, Gergely Nagy a écrit :
> 
> I think that would fit into debian/README.source nicely.

Le Wed, Jun 13, 2012 at 06:54:35PM +0200, Arno Töll a écrit :
> 
> README.source though, as people suggested in IRC.

Le Wed, Jun 13, 2012 at 11:25:43PM +0200, Ansgar Burchardt a écrit :
> 
> I think this information could be located in README.source just as
> well.

Hi all,

I also think that README.source could include information about how the package
is maintained and how to prepare uncoordinated uploads when they are necessary.

There is a proposition to explicitely recommend in the Debian Policy to
document in README.source how to use or behave with the VCS where the source
package is managed, and this could be extended to other informations as well.

  http://bugs.debian.org/495233

Have a nice day,

-- 
Charles Plessy
Tsurumi, Kanagawa, Japan


-- 
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/20120613235114.gb32...@falafel.plessy.net

Re: Maintainers, teams, Uploaders, DMs, DDs, etc.

[Ben Finney]

Arno Töll  writes:

> On 13.06.2012 17:35, Ian Jackson wrote:
> > 1. Change the definition of the Maintainer field to permit multiple
> >entries.
>
> There were probably technical reasons back then when introducing
> Uploaders. Maybe someone knows.

I don't know of technical concerns there.

But I do recall many discussions where a proud benefit of Debian was
said to be that every package has a single person primarily responsible
for it, because this mitigates the diffusion of responsibility we humans
are prone to.

I realise the recent trend has been toward nominating a team as “the”
maintainer.

-- 
 \   “Whenever you read a good book, it's like the author is right |
  `\   there, in the room talking to you, which is why I don't like to |
_o__)   read good books.” —Jack Handey |
Ben Finney


pgpZmmRHSQHaX.pgp
Description: PGP signature

Re: Migration path for 'Multi-Arch:allowed' packages

[Ben Hutchings]

On Wed, 2012-06-13 at 12:47 +0100, Wookey wrote:
> +++ Ben Hutchings [2012-06-13 12:24 +0100]:
> > On Tue, 2012-06-12 at 17:45 +0200, David Kalnischkies wrote:
> > > On Mon, Jun 11, 2012 at 9:40 PM, Michael Gilbert  
> > > wrote:
> > > > In particular, I filed a bug against dpkg requesting that it produce
> > > > more informative error messages in these cases [0], but I wonder if a
> > > > part of the solution shouldn't be more automated or at least presented
> > > > at a higher level through apt/aptitude, etc?
> > > 
> > > Chicken or the egg?
> > > 
> > > You need to upgrade to support MultiArch,
> > > but you need MultiArch to upgrade…
> > > (beside, how would the detection for such a message look like?)
> > [...]
> > > Maybe all maintainers who want to use Multi-Arch now in wheezy
> > > (and therefore drop amd64 packages) should get together and write
> > > a "what to do after the distribution upgrade" for the release notes,
> > > a (low priority) debconf message and if you want to be really fancy
> > > a "transitional" package which shows the same text in case the
> > > "dropped" binaries are executed.
> > [...]
> > 
> > I'd be interested in this for linux-image-amd64:i386.  Currently I
> > expect linux-image-3.2.0--amd64:i386 to remain in wheezy but we'll
> > still need to advise the user to enable amd64 ready for wheezy+1.  If we
> > can document multi-arch well enough in release notes etc. then it might
> > be possible to drop it now.
> 
> I added a user-oriented HOWTO to the multiarch doc-collection last
> month as there seemed to be a shortage of such docs to point to that
> weren't cryptic specifications, or talking mostly about
> cross-building. It may be a useful place to point people, or just lift
> the good bits from it:
> 
> http://wiki.debian.org/Multiarch/HOWTO

That's quite good, but for release notes I think we would need something
that more tersely explains what multiarch means and that you *must*
enable it if you have certain packages installed on certain
architectures.

Ben.

-- 
Ben Hutchings
Computers are not intelligent.  They only think they are.


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