Re: bits from the release team

[Andreas Barth]

* Steinar H. Gunderson ([EMAIL PROTECTED]) [060103 23:37]:
> On Tue, Jan 03, 2006 at 10:45:16PM +0100, Frans Pop wrote:
> > 2.6.8 is not an optimal kernel, but largely due to timing (i.e. SATA just 
> > starting to get implemented).
> 
> The real question (IMHO) is probably whether it would be possible to get
> newer kernels into volatile. I'd guess "probably not", given that stuff like
> udev tends to break every other release, but it's a tempting thought -- the
> sarge machine here seems to run miles better with a 2.6.14 backport (yay for
> backports.org) than it ever did with 2.6.8 (which seems to have a really
> really unstable USB layer).

I think it would be possible, but it requires some help from the kernel
team side - and of course I can understand if they don't want to take
care of yet another kernel version. Please see the discussion starting
at http://lists.debian.org/debian-kernel/2005/12/msg00678.html


Cheers,
Andi
-- 
  http://home.arcor.de/andreas-barth/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: bits from the release team

[Sven Luther]

Sorry for the long mail, but i believe there is something important all the
way done, so if you cannot be bothered to read it all; please go down to the
point marked *IMPORTANT*.

On Tue, Jan 03, 2006 at 10:05:04PM -0800, Steve Langasek wrote:
> You have been harranguing the ftp team to approve new upstream kernels

Wrong, i have asked Gannef to do it quicker NEW handling, and i told him about
this as soon as i found out about the 2.6.15 kernel release, since i believe
infomring folk early is good courtesy if you want them to do stuff for you, as
they can then more easily fit it in their schedule.

Notice that NEW handling is also important in this case, since the
autobuilders will build out of incoming, but not out of NEW, and since kernels
are rather long in building, this is an additional delay.

I may have been more insistent, and thus more dissapointed when it failed to
happen the same day, for the 2.6.14 release, since this one culminated an
intense work session of the whole debian-kernel team to make the
2.6.12->2.6.14 transition with initrd-tools going away and co happen. We are
speaking of 2 to 3 weeks of intense work on the -rc serie, which culminated
in the release, with the claimed aim to do 0-day uploads which many many
believed was not possible, and it didn't happen not for technical reasons, but
for bureaucratic details. You would feal the same, but on a larger scale when
you where about to announce the release, and you couldn't for some stupid
reason fully not under your control and you believe it is an unnecessary
issue. Can you honestly say we wouldn't hear you rant about it afterward ?

But again, this is the second time this happens, so as soon as i knew, i
informed Ganneff, and didn't harrangue or demand or whatever, just informed.
I _did_ rant about the not-really-need for NEW in these cases, but that is
unrelated.

> through the NEW queue before they've even been uploaded -- for an amazing
> false optimization that burns good will with your fellow developers.  Even

Yes, and we are all volunteers, the preparation of a release like the 2.6.14
one had demanded effort and sacrifice from about a dozen persons, do you not
think it burns good will to work on this if you fail to achieve your stated
goal for bureaucratic details, i know my motivation fell a bit when we did
indeed miss dinstall.

> if udebs *were* being built from the same linux-2.6 source package, this
> doesn't address the real reason why it's important to freeze the kernel
> early:  *the kernel is a core component of everyone's system and detecting
> regressions takes a long time*.  Anything that requires a reboot cycle or an

How long a time ? A month, two month, four month ? And what is the cost
balance between backporting all those fixes from the new version, and simply
using the new version.

Also, with the new approach of building -rc releases in experimental, we have
easily another month or so of time to test the kernels, and the possibility to
correct at least part of the issues in upstream before even the release.

But sure, there are issues, but i don't believe they are as time consuming as
you make them.

> installation test in order for users to detect bugs is going to need a
> longer testing period than other packages; the only way to ensure this
> happens is by freezing it early, i.e., around the same time as the toolchain
> packages for which we have the same problem of figuring out whether a new
> version is better or worse.

Bah, ... I can guarantee you users are quick in testing new kernels, part of
them are, and we test them ourself also and run them, so major issues are
found early. we knew about the powerpc debconf/postinst script fuckage before
he package left incoming, altough there was no way to stop it from entering
the archive, and the bug reports came in very very shortly after dinstall.

> The underlying assumption in your plea for a shorter kernel freeze is "newer
> is better".  But people who accept this assumption unconditionally don't
> *run* Debian stable; so neither should we base our freeze timeline on an

Bah, they run stable with sid/experimental or self built kernels, which is the
sanest thing to do, especially given the messy kernel stable security
situation, which i warned you about in april.

> unconditional acceptance of it.  Newer isn't necessarily better, but it is
> necessarily *different*, which is the enemy of stability.

No. the kernel evolves, but more importantly issues get fixed. There are some
newer breakage that may slip in, but all in all the fixing amount overweights
the breakage introduced, and this breakage can be fixed, so i will have to
disagree with this.

But i believe the point is elsewhere, with our current plan, we will always
have two release candidates in the archive, or a single good quality release
candidate. All i ask, and i believe all agree on that, is that the freeze date
and the choice of kernel is done solely on the quality and testing of the
kernel, 

Re: bits from the release team

[Sven Luther]

On Wed, Jan 04, 2006 at 08:58:09AM +0100, Andreas Barth wrote:
> well, the kernel is definitly about the same level as the toolchain and
> standard/base - changes can have very easily impact on the installer,
> and it is not an option to remove the package if it is broken.

Nope, still it is more in the cqtegory of general base than essential
toolchain, but as you said, it is only a week.

> > > > > N-105  = Mon 14 Aug 06: d-i RC [directly after base freeze]
> > > > > N-45   = Wed 18 Oct 06: general freeze [about 2 months after base
> > > > > freeze, d-i RC]
> > > > > N  = Mon  4 Dec 06: release [1.5 months for the general freeze]
> > > > 
> > > > We will have a kernel which is outdated by two versions at release time 
> > > > with
> > > > this plan, since there are about 1 kernel upstream release every 2 
> > > > month.
> > > 
> > > Well, if we want to release with a newer kernel, we need to make sure
> > > d-i doesn't stumble over it. Experience tells us that there are enough
> > 
> > What experience ?
> 
> I was speaking about the installer. And usually there are lots of
> last-minute changes that need to go in - not only new languages, but
> lots of other small minor, but still important bug fixes.

Indeed. I claim that the installer experience gained during the last steps of
the sarge release is worthless for the current situation, as the kernel
situation is lightyears from what it was back then. Failing on your part to
aknowledge this would be a negation or dismissal of the work done by the
kernel team during these past 6 month or so, and i would personally feel
offended, and i believe others will too, if you do this.

It is as if i was takign the boot-floppies experience to take conclusions on
the current installer.

> > > Also, the kernel will be outdated sooner or later anyways - so, if after
> > > one year the kernel is 12 or 14 months old is not too much a difference.
> > 
> > Hehe, me runs sid kernels installed almost as is on all my sarge systems
> > indeed, just with rebuild yaird and mininmally backported udev.
> 
> Well, but then an older kernel doesn't hurt you? :P

Imagine an installer with a known remote security exploit, which brings up the
network early in the install process. This is microsoftian kind of practice,
and i want nothing to do with it, nor my name associated with it, and i
believe the same for you. Still we did, if i remember well, such a kernel in
the sarge installer, solely because the infrastructure didn't allow us to fix
it in a timely fashion.

This is understandable mere month or weeks before the sarge release, but
inexcusable at this point of the release process.

> > Indeed, but you have only the sarge experience to go by, and taking the 
> > sarge
> > experience on this is hardly fair to the huge amount the kernel team has
> > devoted to streamline the process.
> 
> Of course, we have seen that the kernel build process is way more mature
> now. Nobody doubts that.

and that is an euphemism. Still there is doubt about the ability of the kernel
team to be able to think how this maturity can be extended beyond the kernel
team, and there where harsh words about our ability voiced also, which i think
are displaced. so, altough people can't honestly say they doubt it, some still
think they know better with regard to kernel matters, and don't hesitate to
patronize us on this.

> > Also, i don't really believe joeyh and fjp
> > are really the relevant maintainers with regard to the debian kernel and its
> > application, since they lack the vision of how things could go better, or 
> > more
> > thruthfully, probably lack the time and motivation to think really about the
> > issue, and why should they, it is the kernel team jobs :)
> 
> Well, they are definitly the relevant people for the installer. And,
> frankly speaking, at least I have good experience with both of them.

For the installer, sure, but the generation of the d-i kernel .udebs is only
marginally of their relevance, and furthermore they don't want the
responsability associated with it, and as proof i can show you that joeyh
upgraded kernel-wedge and the x86 d-i module udebs, but didn't touch all the
other architectures, defaulting it upto the porters, which are the exact same
guys doing the kernel packages. So joeyh and fjp can't have it both way.

And furthermore this is to make their live easier, so they have more time to
concentrate on more important and core d-i work.

> > d-i is only a part of the problem anyway, and i believe the less 
> > problematic.
> > out-of-tree modules and third-party patches are a worse mess.
> 
> Hm, which out-of-tree modules do you consider to be release critical,
> i.e. we cannot release without them?

Well, i guess once we kick the non-free firmware modules into the non-free
part of linux-2.6, you will reconsider that, or if there are out-of-tree
network or disk drivers. I would say that most of the wlan out-of-tree drivers
already qualify.

Frien

Bug#345909: ITP: qtodo -- Todo List Manager

[Martin Meredith]

Package: wnpp
Severity: wishlist
Owner: Martin Meredith <[EMAIL PROTECTED]>


* Package name : qtodo
  Version : 0.1
  Upstream Author : Tobias [EMAIL PROTECTED]> * URL : http://qtodo.berlios.de/ 
* License : GPL
  Description : Todo List Manager

QTodo is a todo-list manager. It is designed to be simple but powerful and 
focused on helping the user to get things actually done.


-- System Information: Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.15-9-386
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) (ignored: LC_ALL set to C)


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: bits from the release team

[Andrew M.A. Cater]

On Wed, Jan 04, 2006 at 01:13:08AM +0100, Sven Luther wrote:
> On Tue, Jan 03, 2006 at 06:43:28PM -0500, Brian Nelson wrote:
> > [EMAIL PROTECTED] (Marco d'Itri) writes:
> > 
> > 
> > Why don't we use RHEL's kernel, or collaborate with them to maintain a
> > stable kernel tree, or something?
> 
Have you ever actually _used_ a RH kernel / SuSE kernel. Because of
their build processes and because each distributor wants to build
in patches etc. they are hell to rebuild / upgrade.

> Why doesn't debian really collaborate with ubuntu on the kernels, which would
> be more natural. Debian use mostly the mainline upstream kernels, which is
> where everything goes back in anyway, so ...
> 

Ubuntu and Debian can readily share the same kernel maintenance team
if it suits. The problem is - the release cycle of Ubuntu every six
months means it probably won't suit :(

If there is long term support / enterprise server support for an
Ubuntu release (which is planned for next October's release) then this
problem may go away and we may be able to come to some agreement.

Better to use a tested and stable kernel in stable whenever it is
released rather than trying to synch to current kernels sometime too
close to release time just for the sake of releasing a semi-current 
kernel. Two months/four months/six months - provided
its stable it doesn't matter how old it is at the precise moment
of release.

All IMHO

Andy
Andy
> Friendly,
> 
> Sven Luther
> 
> 
> -- 
> To UNSUBSCRIBE, email to [EMAIL PROTECTED]
> with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: How to Increase Contributions from Volunteers

[Andreas Schuldei]

* Manoj Srivastava <[EMAIL PROTECTED]> [2006-01-03 22:30:09]:
> >> They are right: most probably they will find it easier to make
> >> contributions to other projects.
> 
> > we need to promote the easy entry points to contributing to debian
> > more prominently and should hide the "how to become a DD" in
> > comparison.
> 
> What on earth for?

are you asking or do you want to argue a point?

if you are asking: people who want to help/contribute seem to be
turned away by the burecratic nature of the NM process with it's
long waiting periodes. People who want to contribute without that
process need to find a way to do that easily and effectively,
without spending too much time to find where they can do that.

> > we should leave that option for the ones that want to contribute
> > above average.
> 
> We are trying to build the best distribution of linux on the
>  planet, not the so-so ditribution created by the most number of
>  people.  Why do you think that an excellent direbution can come by
>  with contribution of people who are, in your own words, below
>  average? 

Manoj, i think you are trying to polarize the discussion. Please
try not to do that. it does not help to reach a good conclusion.

Please realize that there is a difference between people who want
to *contribute* above average and *people* below average.

One such difference could be technical excellent people who want
to help without spending time on packaging issues (as NM in its
current form often does) but rather on their field of excellence,
which could be coding or graphical design or in the legal area.

Other, merely average people could be willing to do the boring
donkey work of coding, graphical design or legal stuff, unloading
those few geniuses we have. If done properly, even the ones BELOW
average could contribute, be happy and feel appreciate. Luckily
that is possible today already. We dont just need to utilize the
elite for all purposes.

They all could help quicker and more directly if they could be
routed to the places where they are needed *just now* without a
detour over NM. Their help would contribute to making debian the
best distribution. 


signature.asc
Description: Digital signature

Re: dependencies on makedev

[Josselin Mouette]

Le mercredi 04 janvier 2006 à 01:06 +, Stephen Gran a écrit :
> > Can you give us a way to change permissions of a device that can be
> > plugged or unplugged?
> 
> Of course.  With a static /dev/, the node is always there to be operated
> on whether or not there is hardware associated with the device node.
> You can chmod it whether there is a device plugged in or not.

Which is completely unuseful as the device can be mapped to different
hardware later on.

> udev largely solves the problem of 'my /dev tree is ugly with all those
> extra things in it'.  Until it also solves all of the problems it brings
> with it, and provides an upgrade path better than 'upgrade the kernel
> first', I have to remain unconvinced.

It seems you are misunderstanding the purpose of udev. Its most
important benefit is to signal the user space that a device has been
plugged in, through HAL and dbus. The clean /dev tree is only a side
effect.

Furthermore, udev doesn't bring new problems. You can't have a
persistent naming scheme with a static /dev either, unless you are
loading modules by hand. If you still want to load your modules by hand,
udev won't prevent you from doing so.
-- 
 .''`.   Josselin Mouette/\./\
: :' :   [EMAIL PROTECTED]
`. `'[EMAIL PROTECTED]
   `-  Debian GNU/Linux -- The power of freedom

Re: Experiment: poll on "switching to vim-tiny for standard vi?"

[paddy]

On Wed, Jan 04, 2006 at 03:15:01AM +0100, Bernd Eckenfels wrote:
> In article <[EMAIL PROTECTED]> you wrote:
> > I think the single-user system is the last one that alternatives handling
> > should optimize for, since the *one* person who's going to know to type
> > "nvi" instead of "vi", and the one person who can fix the alternatives if he
> > doesn't like them, is the admin...
> 
> which also means he most likely wants to have the manually installed packet
> to grab the alternative link.

Time to add a policy-alternatives hook to update-alternatives ??

Regards,
Paddy
-- 
Perl 6 will give you the big knob. -- Larry Wall


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: How to Increase Contributions from Volunteers

[Thomas Hood]

Andreas Schuldei wrote:
> we need to promote the easy entry points to contributing to debian
> more prominently and should hide the "how to become a DD" in
> comparison.

Manoj Srivastava wrote:
> What on earth for?

Andreas Schuldei wrote:
> [...] people who want to help/contribute seem to be
> turned away by the burecratic nature of the NM process with its
> long waiting periods. People who want to contribute without that
> process need to find a way to do that easily and effectively,
> without spending too much time to find where they can do that.
> [...]
> Manoj, i think you are trying to polarize the discussion.


I think that the discussion is already polarized; there is obviously a sharp
difference of view.  The disagreement is reflected in the inconsistency between
the existence of "easy entry points", which you favor. and the whole philosophy
behind the NM process, which was presumably favored by those who set up that
process.

You seem to be assuming that Debian should encourage people to contribute,
whereas the NM process was deliberately set up to discourage applicants.
You assume that applicants are scarce, but the assumption behind NM is that
there are more than enough. You assume that newcomers can be given the benefit
of the doubt, whereas the assumption behind NM is that newcomers should not be
trusted until they have endured trials.  You assume that contributors are
different, but the assumption behind NM is that developers all need to learn
the same skills.  You assume that people can learn as they go, but NM insists
that applicants learn everything up front.

If there are "easy entry points" in Debian which allow non-DDs to do the same
work as DDs then I can see why a defender of the current NM process would
regard those points as weaknesses in Debian's defenses, which should be closed
rather than advertized.
-- 
Thomas Hood


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: bits from the release team

[Tollef Fog Heen]

* Sven Luther 

| I believe it has also an influence on the place where the source package is
| ohold (alioth svn repo over whatever strange stuff ubuntu uses), and they said
| we should use their system. 

yeah, git, really strange stuff in the world of Linux kernel
development.  Available from
rsync://rsync.kernel.org/pub/scm/linux/kernel/git/bcollins/ubuntu-2.6.git
(or http://www.kernel.org/pub/scm/linux/kernel/git/bcollins/ubuntu-2.6.git/)

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


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

hppa dependency problems on build of pdns

[Matthijs Mohlmann]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi,

I don't know where to send this else, so forgive me if this is the wrong
mailinglist.

See:
http://buildd.debian.org/fetch.php?&pkg=pdns&ver=2.9.19-2&arch=hppa&stamp=1135294848&file=log&as=raw

[..]
Setting up tetex-base (3.0-11) ...
Removing unchanged obsolete conffiles ... done
/var/lib/dpkg/info/tetex-base.postinst: line 678: update-language:
command not found
dpkg: error processing tetex-base (--configure):
 subprocess post-installation script returned error exit status 127
Setting up libexpat1 (1.95.8-3) ...
[..]

[EMAIL PROTECTED] % dpkg -S update-language

tex-common: /usr/sbin/update-language
tex-common: /usr/share/man/man8/update-language.8.gz

[EMAIL PROTECTED] % apt-cache show tetex-base | grep -e ^Version -e ^Depends
Version: 3.0-11
Depends: ucf (>= 1.02), tex-common (>= 0.12)

As you can see, tetex-base depends on tex-common (>= 0.12). But the hppa
build daemon doesn't install tex-common.

So can somebody tell me what's going on here ?

Regards,

Matthijs Mohlmann

(Team member of Debian PowerDNS Maintainers)
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFDu7mu2n1ROIkXqbARAkVkAJ9LcTypOqgWft3e2+R/ns0nV69tYgCfQ3m4
JUB7hM4F9cXwq+mSs9LK00s=
=quYE
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Maintaining a debian package

[Andi Drebes]

Kevin Mark wrote:

> you may notice that  Debian has many programs to catalog thing. Some for
> cd/dvd's, some for books, etc. When you make an ITP you will need to
> make an argument as to why this packages should be added. Debian
> developers will want to know what differentiates your package from other
> similar ones in Debian already. This is not to say that you will be
> unable to add your package to debian, but on rare occasions it has been
> decided that some packages would not benefit being added.
Why did I start the project? I talked to a friend at the university and we
agreed that we've got too many books to keep them all in mind. So we wanted
to have a program to manage them. I searched the internet, especially
freshmeat and sourceforge for an adequate project fitting to our needs. I
didn't search for a long time, but in fact, I didn't find that, what I
wanted. I decided to write this program on my own. I wanted to create an
easy to use program which doesn't annoy users with the creation of
databases and long setup procedures.

> ps. If you want some beta tester for your work, you should include a URL
> so that folks like me can try your work, assuming you feel it is in a
> shape to be tested.
There's a website where I place the sourcecode and also the latest binary
version (including the ChangeLog and so on). You can get it here:
http://drebesium.ath.cx/~hackbert/wxbiblio/dist/
There are also some screenshots:
http://drebesium.ath.cx/~hackbert/wxbiblio/screenshots/
It might be, that one doesn't get the program to compile and work correctly.
This is due to some problems I have with autoconf and automake. I hope I
can fix this in the next time. By the way, the program is called wxbiblio
as you might have recognized when having a look on the URL. It is entirely
written in C and C++ and uses wxWidgets for the GUI. Xerces-c is also
needed, because I use it to read data from XML-files. It would be cool, if
somebody wanted to test it. Feel free to download, distribute and modify
it. You may also write me emails.

Andi

P.S.: I'm currently reading all the stuff about how to publish packages in
the debian directories. That's kind of complicated and seems to be a long
procedure. Nevertheless, I think it's required to keep the good quality of
debian packages. On the other hand, it discourages me a bit to become a
maintainer. Well, I'll go on reading and decide later :)


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: bits from the release team

[Sven Luther]

On Wed, Jan 04, 2006 at 12:39:09PM +0100, Tollef Fog Heen wrote:
> * Sven Luther 
> 
> | I believe it has also an influence on the place where the source package is
> | ohold (alioth svn repo over whatever strange stuff ubuntu uses), and they 
> said
> | we should use their system. 
> 
> yeah, git, really strange stuff in the world of Linux kernel

Ah, could, it used to be bazar thingy, or arch previously, which is one of the
most non-friendly tools out there.

Friendly,

Sven Luther


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: bits from the release team

[martin f krafft]

also sprach Brian Nelson <[EMAIL PROTECTED]> [2006.01.04.0043 +0100]:
> Why don't we use RHEL's kernel, or collaborate with them to maintain a
> stable kernel tree, or something?

I doubt RH has the same concept of stability as we do, and I surely
don't want a plethora of potentially untested or buggy hardware
support patches in my productive kernels.

-- 
Please do not send copies of list mail to me; I read the list!
 
 .''`. martin f. krafft <[EMAIL PROTECTED]>
: :'  :proud Debian developer and author: http://debiansystem.info
`. `'`
  `-  Debian - when you have better things to do than fixing a system
 
Invalid/expired PGP (sub)keys? Use subkeys.pgp.net as keyserver!
 
gentoo: for when you finally find out
that overclocking can kill your processor.


signature.asc
Description: Digital signature (GPG/PGP)

Re: How to Increase Contributions from Volunteers

[Kevin Mark]

On Wed, Jan 04, 2006 at 12:20:07PM +0100, Thomas Hood wrote:
> Andreas Schuldei wrote:
> > we need to promote the easy entry points to contributing to debian
> > more prominently and should hide the "how to become a DD" in
> > comparison.
> 
> Manoj Srivastava wrote:
> > What on earth for?
> 
> Andreas Schuldei wrote:
> > [...] people who want to help/contribute seem to be
> > turned away by the burecratic nature of the NM process with its
> > long waiting periods. People who want to contribute without that
> > process need to find a way to do that easily and effectively,
> > without spending too much time to find where they can do that.
> > [...]
> > Manoj, i think you are trying to polarize the discussion.
> 
> 
> I think that the discussion is already polarized; there is obviously a sharp
> difference of view.  The disagreement is reflected in the inconsistency 
> between
> the existence of "easy entry points", which you favor. and the whole 
> philosophy
> behind the NM process, which was presumably favored by those who set up that
> process.
> 
> You seem to be assuming that Debian should encourage people to contribute,
> whereas the NM process was deliberately set up to discourage applicants.
> You assume that applicants are scarce, but the assumption behind NM is that
> there are more than enough. You assume that newcomers can be given the benefit
> of the doubt, whereas the assumption behind NM is that newcomers should not be
> trusted until they have endured trials.  You assume that contributors are
> different, but the assumption behind NM is that developers all need to learn
> the same skills.  You assume that people can learn as they go, but NM insists
> that applicants learn everything up front.
> 
> If there are "easy entry points" in Debian which allow non-DDs to do the same
> work as DDs then I can see why a defender of the current NM process would
> regard those points as weaknesses in Debian's defenses, which should be closed
> rather than advertized.
> -- 
> Thomas Hood
Hi Thomas,
almost all of the discussion about 'contributing' seems to focus on
doing development work on packages. So Debian wants it to be a
weeding-out process-thus the NM process. But are there any other types
of contribution that can be encouraged by making a clear list and howto?

translators, bandwith hosts, sponsors for debian events, supporting
debian-user and irc, LUGs that hold 'debian day' and pass out cd's,
creating forum for users to encourage/support local business/governemt to move 
to
debian. Selling lance armstrong-type red swirl bracelets? 

These are but a few ideas, of which I think some are already on the website.

To contribute to debian while primarlly involves MAKING it, there are
other less technical and/or social things that may bring
people/interest/money to our efforts like support and fandom. 
One area where less technical folks can surely help is
Documentations(Osamu Aoki yea!), proofreading debian documents in all of
our various languages, some of which require translations.(Christian
Perrier yea!) And for people who want to learn the step/skills to become
DD's, maybe a DD can create a work book/pdf that would list important
skills, websites to visit and exercises that should be attempted to be
better prepared for NM. Would it be better if NM's were given a study
guide before the NM process? Why not use some of the older DD NM test
material for this. And prehaps a seperate guide for folks intending to
be translators as Debian thinks they need NM skills of some degree.  
Again, these may all be in the debian-devel or -mentor site.

anyway, Debian should make SOME area easier, not ones involving code.
pax vobiscum,
Kev
-- 
counter.li.org #238656 -- goto counter.li.org and be counted!
  `$' $' 
   $  $  _
 ,d$$$g$  ,d$$$b. $,d$$$b`$' g$b $,d$$b
,$P'  `$ ,$P' `Y$ $$'  `$ $  "'   `$ $$' `$
$$ $ $$g$ $ $ $ ,$P""  $ $$
`$g. ,$$ `$$._ _. $ _,g$P $ `$b. ,$$ $$
 `Y$$P'$. `YP $$$P"' ,$. `Y$$P'$ $.  ,$.


signature.asc
Description: Digital signature

Re: Debian for desktop - gnome in usnstable/experimantal more stable than in testing ?

[Thomas Dickey]

Benjamin Mesing <[EMAIL PROTECTED]> wrote:

>> I can't see any mention of xterm in packagesearch's changelog, nor any bugs
>> filed about the problem, either.
> Look at changelog.gz, probably I should have copied it to
> changelog.Debian.gz too. Bugs were not filed against this problem. And
> to be honest it might _not_ have occured in testing. I've never checked
> when xterm changed in its behaviour, and if this xterm version made the

still, if you're talking about a bug, you should report it.
The only relevant one I recall was breakage in #202, which was
reported by two other people.  It's fixed in the package #204.
208 is current...

-- 
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Packages still Depending on xlibs-dev

[Daniel Schepler]

With the recent upload of xorg-x11 version 6.9.0 to unstable removing 
xlibs-dev, any package still having a Depends: xlibs-dev will become 
uninstallable very soon once xlibs-dev disappears from the distribution.  
Here's a list of the affected packages from main/i386 by maintainer; filing 
of grave bugs to follow once this happens.  (Also, everybody correct any 
Build-Depends on xlibs-dev as well.)

Ryuichi Arafune <[EMAIL PROTECTED]>
   libmagick9-dev

Hakan Ardo <[EMAIL PROTECTED]>
   toolchain-source

Thomas Bushnell, BSG <[EMAIL PROTECTED]>
   gdk-imlib11-dev
   imlib11-dev
   libgnome-dev

A. Maitland Bottoms <[EMAIL PROTECTED]>
   libvtk4-dev

Martin Buck <[EMAIL PROTECTED]>
   xviewg-dev

Guenter Geiger <[EMAIL PROTECTED]>
   ivtools-dev

Debian QA Group <[EMAIL PROTECTED]>
   libubit-dev

Christian Hudon <[EMAIL PROTECTED]>
   iconc

Aurelien Jarno <[EMAIL PROTECTED]>
   liblineak-dev

Siggi Langauf <[EMAIL PROTECTED]>
   libxine-dev

Steve M. Robbins <[EMAIL PROTECTED]>
   libsoqt-dev

Jeff Teunissen <[EMAIL PROTECTED]>
   libdockapp-dev

Chris Waters <[EMAIL PROTECTED]>
   itk3.0-dev
   itk3.1-dev
   tk8.0-dev
   tk8.3-dev

Florian M. Weps <[EMAIL PROTECTED]>
   libooc-x11-dev

Mathias Weyland <[EMAIL PROTECTED]>
   beep-media-player-dev

(Btw, dd-list should probably have an option to suppress converting to source 
packages, for situations like this where a list of binary packages is more 
useful.)
-- 
Daniel Schepler


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: bits from the release team

[Gabor Gombas]

On Wed, Jan 04, 2006 at 12:23:31AM -0200, Felipe Augusto van de Wiel (faw) 
wrote:

>   Perhaps the idea of maintain a kernel with other distros is not bad,
> if Ubuntu shows up as a candidate, I would like to add Progeny, Linspire,
> Xandros, "DCC Alliance Fan Club" and also other Debian Derivatives. I really
> don't know if it is possible to mix RH, Debian, SuSE, Slackware and
> other distros to maintain the same kernel, but certainly should be possible
> to get all Debian (and Debian based/derivative) playing together. :-)

Different distros have different target audiences so this may not be
easy. Often fixing a driver bug for one class of users breaks it for an
other class of users so it is quite possible that different distros want
different bugs to be fixed/left alone.

Also, other distros (e.g. RedHat) already found out the hard way that
diverging too much from upstream costs a lot. So unless you find someone
to pay the maintainers of such a forked kernel, it will not work out in
the long term.

>   If you give it a quick look (and a quick try), we will have more
> users testing the same kernel, which means more feedback, we will have
> more developers working to get it stable and working to get it secure.
> Probably even upstream get benefits from this model and sounds like a very
> good way to work together, even to try to integrate outside patches and
> backporting things. =)

Dave Jones (Fedora) and Greg KH (Gentoo) already posted a much better idea
on l-k: make packages from daily -git snapshots available for distro
testers, so bugs like the past udev breakages are found _before_ the
next official kernel version is released.

Packaging at least -rc kernels for unstable might be a good idea for
Debian too. That would provide more testing coverage for -rc releases,
and this is what upstream needs the most.

Gabor

-- 
 -
 MTA SZTAKI Computer and Automation Research Institute
Hungarian Academy of Sciences
 -


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: bits from the release team

[Gabor Gombas]

On Tue, Jan 03, 2006 at 10:43:55PM +0100, Julien BLACHE wrote:

> I wonder how that's going to happen wrt udev and a couple of other
> things that, as of today, depend on a precise version of the kernel.

The udev breakages were rather annoying but the situation is not as bad
as it looks. ALSA for example is worse but it gets less "press coverage".

To avoid such breakages in the future,

- test -rc kernels as they come out
- complain loudly on linux-kernel if something breaks (just cursing on
  debian-devel will not help)

Gabor

-- 
 -
 MTA SZTAKI Computer and Automation Research Institute
Hungarian Academy of Sciences
 -


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: dependencies on makedev

[Gabor Gombas]

On Wed, Jan 04, 2006 at 11:52:58AM +0100, Josselin Mouette wrote:

> Furthermore, udev doesn't bring new problems. You can't have a
> persistent naming scheme with a static /dev either, unless you are
> loading modules by hand. If you still want to load your modules by hand,
> udev won't prevent you from doing so.

Even that will not help you if an SCSI/SATA device fails and thus the
other devices get renamed. And with the current work to port the old
IDE drivers to libata, this may be the issue with practically every disk
in the not so distant future.

Gabor

-- 
 -
 MTA SZTAKI Computer and Automation Research Institute
Hungarian Academy of Sciences
 -


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: bits from the release team

[Steinar H. Gunderson]

On Wed, Jan 04, 2006 at 02:03:00PM +0100, Gabor Gombas wrote:
> The udev breakages were rather annoying but the situation is not as bad
> as it looks. ALSA for example is worse but it gets less "press coverage".

Are you serious?

udev has broken my system -- completely (as in: can't boot and/or log in) --
_seven_ distinct times since this summer. How on you can claim that ALSA is
worse, is beyond me :-)

/* Steinar */
-- 
Homepage: http://www.sesse.net/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: bits from the release team

[Marco d'Itri]

On Jan 04, "Steinar H. Gunderson" <[EMAIL PROTECTED]> wrote:

> udev has broken my system -- completely (as in: can't boot and/or log in) --
> _seven_ distinct times since this summer. How on you can claim that ALSA is
> worse, is beyond me :-)
This was not always caused by udev bugs.
And anyway, it's called unstable for a reason. udev in stable is stable.

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Re: bits from the release team

[Josselin Mouette]

Le mercredi 04 janvier 2006 à 14:21 +0100, Marco d'Itri a écrit :
> On Jan 04, "Steinar H. Gunderson" <[EMAIL PROTECTED]> wrote:
> 
> > udev has broken my system -- completely (as in: can't boot and/or log in) --
> > _seven_ distinct times since this summer. How on you can claim that ALSA is
> > worse, is beyond me :-)
> This was not always caused by udev bugs.
> And anyway, it's called unstable for a reason. udev in stable is stable.

Unstable means dependencies can be broken, not that packages themselves
can always broken. Each and every single package uploaded to unstable
should be of release quality. Otherwise, it should go to experimental.
-- 
 .''`.   Josselin Mouette/\./\
: :' :   [EMAIL PROTECTED]
`. `'[EMAIL PROTECTED]
   `-  Debian GNU/Linux -- The power of freedom

Re: bits from the release team

[Maximilian Attems]

On Wed, Jan 04, 2006 at 01:51:17PM +0100, Gabor Gombas wrote:

> 
> Packaging at least -rc kernels for unstable might be a good idea for
> Debian too. That would provide more testing coverage for -rc releases,
> and this is what upstream needs the most.

the -rc kernels are build in experimental, staging area for unstable
and without any potential d-i breakage.

-- 
maks


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Experiment: poll on "switching to vim-tiny for standard vi?"

[Steve Greenland]

On 04-Jan-06, 05:08 (CST), paddy <[EMAIL PROTECTED]> wrote: 
> Time to add a policy-alternatives hook to update-alternatives ??

Huh? If the admin manually sets an alternative with with
update-alternatives, it won't be overridden by a package install. What
more does she need?

Steve


-- 
Steve Greenland
The irony is that Bill Gates claims to be making a stable operating
system and Linus Torvalds claims to be trying to take over the
world.   -- seen on the net


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Experiment: poll on "switching to vim-tiny for standard vi?"

[Steve Greenland]

On 03-Jan-06, 19:30 (CST), Steve Langasek <[EMAIL PROTECTED]> wrote: 
> On Tue, Jan 03, 2006 at 08:58:49AM -0600, Steve Greenland wrote:
> > Such behaviour is pretty much standard alternative handling: the default
> > install is the lowest priority, and the optional variants have higher
> > priorities.
> 
> > For a single user system, this makes sense. For a multi-user system,
> > where the admin might want all of (vim, nvi, vile, whatever) as options
> > for the user, it's easy to pick whichever one you want for the default.
> 
> OTOH, the admin may not understand the alternatives system, or recognize its
> relevance at the time of installing the package (worst case, some other
> package pulls it in automatically), which makes for an inconsistent user
> experience.
> 
> I think the single-user system is the last one that alternatives handling
> should optimize for, since the *one* person who's going to know to type
> "nvi" instead of "vi", and the one person who can fix the alternatives if he
> doesn't like them, is the admin...

Then you need to bring this up on -policy, because what I described
(that the default package providing an alternative is the lowest
ranked one, and the optional ones override it) is what people have
been doing for years. See, for example, mawk and gawk. Or even vi: by
your argument, nvi should currently be the highest ranked of the vi
alternatives, not the lowest.

Steve

-- 
Steve Greenland
The irony is that Bill Gates claims to be making a stable operating
system and Linus Torvalds claims to be trying to take over the
world.   -- seen on the net


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: bits from the release team

[Norbert Tretkowski]

* Gabor Gombas wrote:
> Packaging at least -rc kernels for unstable might be a good idea for
> Debian too. That would provide more testing coverage for -rc releases,
> and this is what upstream needs the most.

We already had some -rc releases in experimental for 2.6.14 and
2.6.15.

Norbert


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: How to Increase Contributions from Volunteers

[Zak B. Elep]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi Andreas!

On 1/4/06, Andreas Schuldei <[EMAIL PROTECTED]> wrote:
> Please realize that there is a difference between people who want
> to *contribute* above average and *people* below average.

While I agree that there are contributions that are either above, below,
or just the average, I wouldn't try to make a point on the basis of
quantitizing contributions.  For all you know, there are other persons,
indeed persons like you, who take pride of their work, no matter how big
or small it may seem to be in your eyes.

I feel that a better metric of contribution fall on the dedication and
`heart' of contributing; but alas, there's not much of a way to
quantitize that (dedication, mayhaps...)

> They all could help quicker and more directly if they could be
> routed to the places where they are needed *just now* without a
> detour over NM. Their help would contribute to making debian the
> best distribution.

Hmm, perhaps they could use some hints not just on the Developers'
Corner,[1] but also on the main page?[2] While I must say the main
Debian page is jam-packed with news and security updates, I find it too
bare for those in the want of contributing; there's just the Corner
link.

[1]  http://www.debian.org/devel/
[2]  http://www.debian.org/

Just one thing ought to be sure; whatever things may go, a serious
contributor will remain unfazed in contributing to Debian.  I just hope
that we somehow get out of this rut.

Cheers,

Zakame

- --
Zak B. Elep  ||  http://zakame.spunge.org
[EMAIL PROTECTED]  ||  [EMAIL PROTECTED]
1486 7957 454D E529 E4F1  F75E 5787 B1FD FA53 851D

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFDu9PVV4ex/fpThR0RAnLbAKCu1Q5VtSTb+//ljfg7i/RWKhmnNwCgpE1w
w99hli4EoCggmfQK8mfgA1c=
=P+Wn
-END PGP SIGNATURE-

Re: Packages still Depending on xlibs-dev

[Kevin B. McCarty]

Daniel Schepler wrote:

> With the recent upload of xorg-x11 version 6.9.0 to unstable removing 
> xlibs-dev, any package still having a Depends: xlibs-dev will become 
> uninstallable very soon once xlibs-dev disappears from the distribution. 

If you're following this, could you please check that the wiki page is
up to date at http://wiki.debian.org/DependsXlibsDev ?

Thanks,

-- 
Kevin B. McCarty <[EMAIL PROTECTED]>   Physics Department
WWW: http://www.princeton.edu/~kmccarty/Princeton University
GPG: public key ID 4F83C751 Princeton, NJ 08544


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: How to Increase Contributions from Volunteers

[Manoj Srivastava]

On Wed, 4 Jan 2006 11:39:55 +0100, Andreas Schuldei <[EMAIL PROTECTED]> said: 

> * Manoj Srivastava <[EMAIL PROTECTED]> [2006-01-03 22:30:09]:
>> >> They are right: most probably they will find it easier to make
>> >> contributions to other projects.
>> 
>> > we need to promote the easy entry points to contributing to
>> > debian more prominently and should hide the "how to become a DD"
>> > in comparison.
>> 
>> What on earth for?

> are you asking or do you want to argue a point?

Depends on how you take it, I guess.

> if you are asking: people who want to help/contribute seem to be
> turned away by the burecratic nature of the NM process with it's
> long waiting periodes. People who want to contribute without that
> process need to find a way to do that easily and effectively,
> without spending too much time to find where they can do that.

The NM process  has the goal of a) ensuring that people who
 can run code as root on myriads of machines of Debian users have
 demonstrated a modicum of competence, and b) these people have agreed
 to uphold the principles and share the common cause that drives
 Debian, c) there is a minimal assurance that one knows who these
 people are, and, possibly, d) these people stand up and demosntrate
 some dedication to the project, so the trust palced in them is not
 misplaced.


People who do not want to undergo that process can just help
 out current developers, fix bugs, send patches, etc. But
 responsibility can only be given to people who actually demonstrate
 the 4 points above; the quality of Debian is at stake.

>> > we should leave that option for the ones that want to contribute
>> > above average.
>> 
>> We are trying to build the best distribution of linux on the
>> planet, not the so-so ditribution created by the most number of
>> people.  Why do you think that an excellent direbution can come by
>> with contribution of people who are, in your own words, below
>> average?

> Manoj, i think you are trying to polarize the discussion. Please try
> not to do that. it does not help to reach a good conclusion.

So say you. I think you are the one polarizing the discussion
 as much as I, proposing that we throw open the Debian project
 products to the whole wide world out there. One can just look at Red
 Hat contrib areas to see how well that works.

> Please realize that there is a difference between people who want to
> *contribute* above average and *people* below average.

I am not sure I want "below average" contributions, if you are
 talking about quality. If you are talking about dilettantes, heck,
 the can contribute via patches sent to the BTS. Recognition should be
 commensurate with the effort spent; tyros and dilettantes get less
 recognition than people who are committed to the project and do the
 heavy lifting.

> One such difference could be technical excellent people who want to
> help without spending time on packaging issues (as NM in its current
> form often does) but rather on their field of excellence, which
> could be coding or graphical design or in the legal area.

I have no objection to creating ways apart from the BTS where
 such effort can be funneled into the project. I am merely vocing
 objections to lowering the bar for people who are responsible for
 Debian packages, and can thus run code as root on my machine


> They all could help quicker and more directly if they could be
> routed to the places where they are needed *just now* without a
> detour over NM. Their help would contribute to making debian the
> best distribution.

The "Help Debian" link on the web page is too obscure?

manoj
-- 
Living on Earth may be expensive, but it includes an annual free trip
around the Sun.
Manoj Srivastava   <[EMAIL PROTECTED]>  
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: How to Increase Contributions from Volunteers

[Roger Leigh]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Manoj Srivastava <[EMAIL PROTECTED]> writes:

> On Wed, 4 Jan 2006 11:39:55 +0100, Andreas Schuldei <[EMAIL PROTECTED]> said: 
>> Please realize that there is a difference between people who want to
>> *contribute* above average and *people* below average.
>
> I am not sure I want "below average" contributions, if you are
>  talking about quality. If you are talking about dilettantes, heck,
>  the can contribute via patches sent to the BTS. Recognition should be
>  commensurate with the effort spent; tyros and dilettantes get less
>  recognition than people who are committed to the project and do the
>  heavy lifting.

In the case of someone who attaches a patch to a bug report, I think
getting a mention in the Debian (or upstream) ChangeLog is sufficient.
I generally also even mention bug submitters in the Debian changelog,
as a way of thanking them for the time they took to identify and
investigate a bug.  I treat both fellow developers and non-developers
the same in this respect.

Realistically, what more can we do?


Regards,
Roger

- -- 
Roger Leigh
Printing on GNU/Linux?  http://gimp-print.sourceforge.net/
Debian GNU/Linuxhttp://www.debian.org/
GPG Public Key: 0x25BFB848.  Please sign and encrypt your mail.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.8+ 

iD8DBQFDu/NXVcFcaSW/uEgRArPmAJ98YU6OyI/WHxNfFuJswUKCwsXV9ACg2Z4+
DLP/W55IKPS97xf2DM1eRgs=
=RZDz
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: bits from the release team

[Gabor Gombas]

On Wed, Jan 04, 2006 at 02:19:31PM +0100, Steinar H. Gunderson wrote:

> udev has broken my system -- completely (as in: can't boot and/or log in) --
> _seven_ distinct times since this summer. How on you can claim that ALSA is
> worse, is beyond me :-)

That's why I said udev breakage is rather annoying. But according to
recent posts on linux-kernel, ALSA broke the kernel-user space ABI much
more often, and technically it is worse and harder to fix than a bug in
udev (even if it is less annoying because only sound breaks).

Gabor

-- 
 -
 MTA SZTAKI Computer and Automation Research Institute
Hungarian Academy of Sciences
 -


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Packages still Depending on xlibs-dev

[Bas Zoetekouw]

Hi Daniel!

You wrote:

> Debian QA Group <[EMAIL PROTECTED]>
>libubit-dev

Maybe this package should just be removed?  It doesn't have any reverse
dependencies afaics, and hasn't had a non-QA upload since feb 2004.

Greetings,
Bas.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: bits from the release team

[Gabor Gombas]

On Wed, Jan 04, 2006 at 02:26:51PM +0100, Maximilian Attems wrote:

> the -rc kernels are build in experimental, staging area for unstable
> and without any potential d-i breakage.

Ah, nice, I did not notice it. Perhaps it should get some more publicity
to attract more testers :-)

Gabor

-- 
 -
 MTA SZTAKI Computer and Automation Research Institute
Hungarian Academy of Sciences
 -


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Debian for desktop - gnome in usnstable/experimantal more stable than in testing ?

[Anthony Towns]

On Tue, Jan 03, 2006 at 10:19:13AM -0500, Benjamin Mesing wrote:
> Also note that it
> was only one feature of packagesearch which broke (after all
> packagesearch does only recommend xterm and works without it). But my
> point was that such (unforseeable) things might break things in testing.

Sure, so the right answer is to understand what happened, work out why it
happened, and see what we can do to make sure it doesn't happen again.

Even then, you'll never get zero breakage ever, but continually reducing
the classes of breakage is a worthwhile activity in and of itself.

> But I have taken the point of the replies. Second hand experience is
> nothing I will base my judgement on (and make it public) any more.
>
> So please disregard my statement against "testing"

I'd suggest a better approach is to take the second hand experience,
try reproducing it in more concrete form, and work out what we can do
to avoid it in future.

This is all software, so doing it is pretty much just an exercise in working
out exactly what we actually want to have happen.

(In this case, xterm could have had a conflict with your package to
avoid screwing users over unnoticed; and we could (in future) have added
a note to the testing scripts to not allow upgrades of xterm until a
fixed version of packagesearch is also included)

The only problem is, we can't fix these problems if we only hear vague
descriptions after the fact. Precise ones after the fact, or vague ones that
are still current, otoh, we have a chance at.

Cheers,
aj
 


signature.asc
Description: Digital signature

Re: How to Increase Contributions from Volunteers

[Anthony Towns]

On Wed, Jan 04, 2006 at 12:20:07PM +0100, Thomas Hood wrote:
> You seem to be assuming that Debian should encourage people to contribute,
> whereas the NM process was deliberately set up to discourage applicants.
> You assume that applicants are scarce, but the assumption behind NM is that
> there are more than enough. 

For those playing along at home, Thomas recently withdrew his application
from n-m after some absurdly long delays, and declined to withdraw the
withdrawal when a number of developers, including his application manager,
offered assistance. As an obvious corollory Thomas doesn't have access to
the -private archives where the NM process was developed, so shouldn't
be taken as an authority on the assumptions behind NM, or the reasons
for which the NM process was setup.

Anyway, the real point of replying was for me to have some fun playing
(what I'll hereby dub) the false dichotomy game. That's where you take
a set of contradictory statements, and setup reasonable scenarios where,
in fact, both alternatives are true simultaneously.

> You assume that newcomers can be given the benefit
> of the doubt, whereas the assumption behind NM is that newcomers should not be
> trusted until they have endured trials.  

This one's good because there are a variety of responses. A simple one is
to give people the benefit of the doubt in how they handle their trials.
But it's not really quite on point, since the real question is whether
one should have faith in people's innate goodness, or whether you should
protect yourself against bad apples. Most of what I want to say about that
I've already blogged [0] in response to a post of Joey Hess's [1] though.

An interesting possibility worth mentioning is to make the trial be
seeing what they do when given the benefit of the doubt: that requires
a few things, notably scaled levels of trust, and an ability to recover
from instances where your trust turns out to be unfounded.

> You assume that contributors are
> different, but the assumption behind NM is that developers all need to learn
> the same skills.  

(This is counterfactual, since NM includes at least two classes of
applicants who need to learn different skills, namely packagers and
documenters, and AMs can of course make whatever special cases they
see fit. It's also the opposite of Thomas's experience in withdrawing
his application too, given his response to offers of assistance from
his AM and other developers was to indicate he didn't want the special
treatment that would imply. But we shouldn't let reality spoil our
passing amusements)

This one's a little bit too easy, really: people who are different aren't
necessarily different in every particular aspect. An obvious commonality
between Debian contributors is that the contribute to Debian; and it's
not much of a step from there to assume there's a variety of common
things they need to be familiar with.

> You assume that people can learn as they go, but NM insists
> that applicants learn everything up front.

NM is actually a good example of how both these things can be true at
once; all the things you need to know up front before being a developer,
you can happily learn as you go through the NM process.

Another way of looking at this is that education often has two parts:
learning and testing; that NM focusses on the latter component, doesn't
mean anything for the former -- you can learn however you like, as you
go, cramming, hypnosis, you just need to realise that testing, and NM,
comes after the fact.

> If there are "easy entry points" in Debian which allow non-DDs to do the same
> work as DDs then I can see why a defender of the current NM process would
> regard those points as weaknesses in Debian's defenses, which should be closed
> rather than advertized.

As someone who thinks the current NM process is horribly bureaucratic
and broken (both in being too hard for good people, and probably actively
filtering for people who like bureaucracy), I also regard sponsorship as
a flaw in Debian's process, which should be removed and replaced. I'll
cite bugs 308877 and 306791 as random examples.

Isn't being ornery fun?

Cheers,
aj

[0] http://azure.humbug.org.au/~aj/blog/2005/12/07
[1] 
http://kitenet.net/~joey/blog/entry/ending_the_tyranny_of_unix_permissions-2005-12-06-19-03.html



signature.asc
Description: Digital signature

Re: installing gallery

[Nico Golde]

Hello Alejandro,

* Alejandro Bonilla Beeche <[EMAIL PROTECTED]> [2006-01-03 13:11]:
> This should not be an email for this ML, but anyway, I think 
> this version of gallery could be kind of broken as I have used 
> the Sid one and works like a charm. This is a little box that I 
> have with gallery and my web services. I think it most be 
> apache2 the one giving a hard time here.

[...] 
Please choose one of the user mailinglists [1] for this 
questions because it is not directly developer related.
If noone can help you and you really think it's a bug and 
not a misconfiguration consider to file a bug using the 
`reportbug` tool.

[1] http://lists.debian.org/users.html

Kind Regards
Nico Golde
-- 
Nico Golde - JAB: [EMAIL PROTECTED] | GPG: 0x73647CFF
http://www.ngolde.de | http://www.muttng.org | http://grml.org
Forget about that mouse with 3/4/5 buttons -
gimme a keyboard with 103/104/105 keys!


pgp3RRcHi72hg.pgp
Description: PGP signature

Bug#345977: ITP: polld -- Polling demon

[Michal Čihař]

Package: wnpp
Severity: wishlist
Owner: "Michal Čihař" <[EMAIL PROTECTED]>

* Package name: polld
  Version : 0.2
  Upstream Author : Michal Čihař <[EMAIL PROTECTED]>
* URL : http://www.cihar.com/software/polld
* License : GPL
  Description : Polling demon

This demon periodically opens devices (files) listed in configuration.
Main reason is to force rescanning of partitions on usb devices while
using udev.

-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.14-2-686
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug#345977: ITP: polld -- Polling demon

[Roger Leigh]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Michal Čihař <[EMAIL PROTECTED]> writes:

> This demon periodically opens devices (files) listed in configuration.
> Main reason is to force rescanning of partitions on usb devices while
> using udev.

What is the problem this is trying to solve?

If the partition table is being changed, the tool that changed it
should issue a BLKRRPART ioctl, like fdisk does for example (see
).


Regards,
Roger

- -- 
Roger Leigh
Printing on GNU/Linux?  http://gimp-print.sourceforge.net/
Debian GNU/Linuxhttp://www.debian.org/
GPG Public Key: 0x25BFB848.  Please sign and encrypt your mail.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.8+ 

iD8DBQFDvAOjVcFcaSW/uEgRArDAAJ9vUxE3TWr+iIkn4TvCD7GtTt5PiACghFoJ
W1FS6fucsy+nqJrq/bcwHxI=
=xf+6
-END PGP SIGNATURE-

Re: Bug#345977: ITP: polld -- Polling demon

[Nathan Poznick]

Thus spake Roger Leigh:
> What is the problem this is trying to solve?
> 
> If the partition table is being changed, the tool that changed it
> should issue a BLKRRPART ioctl, like fdisk does for example (see
> ).

I have a USB card reader which has 5 different slots for various media.
If I plug in the card reader and then later insert a CF card, the CF
card slot's device does not have the partition device created when using
udev (I have to insert the CF card and then plug in the card reader).  I
believe this software is created specifically for that purpose - for
card readers which do not report card insertion / removal to the kernel.

-- 
Nathan Poznick <[EMAIL PROTECTED]>

The world is not growing worse and it is not growing better-it is just
turning around as usual. - Finley Peter Dunne



signature.asc
Description: Digital signature

Aptitude question

[Jiri Palecek]

Hello,
I have a question on how aptitude decides which packages
to install to satisfy dependencies. I was installing vtk yesterday
and it depends on xlibmesa-gl | libgl1. Aptitude chose to install
xlibmesa-gl which in turn broke my x-window-system-core
metapackage. However, I was able to manually fix it by
using libglu1-xorg for the dependency (and I needed to downgrade it).

How does aptitude decide which one to choose? Shouldn't it
prefer to do something that won't break other packages? Or should
it ask the user for help?

  Jiri Palecek
__
XXL-Speicher, PC-Virenschutz, Spartarife & mehr: Nur im WEB.DE Club!
Jetzt gratis testen! http://freemail.web.de/home/landingpad/?mc=021130


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: bits from the release team

[Brian Nelson]

Josselin Mouette <[EMAIL PROTECTED]> writes:

> Le mercredi 04 janvier 2006 à 14:21 +0100, Marco d'Itri a écrit :
>> On Jan 04, "Steinar H. Gunderson" <[EMAIL PROTECTED]> wrote:
>> 
>> > udev has broken my system -- completely (as in: can't boot and/or log in) 
>> > --
>> > _seven_ distinct times since this summer. How on you can claim that ALSA is
>> > worse, is beyond me :-)
>> This was not always caused by udev bugs.
>> And anyway, it's called unstable for a reason. udev in stable is stable.
>
> Unstable means dependencies can be broken, not that packages themselves
> can always broken. Each and every single package uploaded to unstable
> should be of release quality. Otherwise, it should go to experimental.

Dude, how many people do you think would test a udev package in
experimental?  I could count them on one hand.  It's impossible to get a
package like udev to be of "release quality" if no one tests it.

-- 
Captain Logic is not steering this tugboat.

Re: bits from the release team

[Joey Hess]

Sven Luther wrote:
> For the installer, sure, but the generation of the d-i kernel .udebs is only
> marginally of their relevance, and furthermore they don't want the
> responsability associated with it, and as proof i can show you that joeyh
> upgraded kernel-wedge and the x86 d-i module udebs, but didn't touch all the
> other architectures, defaulting it upto the porters, which are the exact same
> guys doing the kernel packages. So joeyh and fjp can't have it both way.

Um, I maintain kernel-wedge and linux-kernel-di-i386*. Not having access
to every other architecture out there, and with some of the
architectures that I do have access to suffering from unaddressed kernel
bugs (ie #332962) that make my hardware for them useless for testing new
d-i releases, as well as being limited to modem speeds, makes it
difficult to maintain anything more.

If you take a closer look at the commits in question, my changes were
limited to kernel-wedge, which means the maintainers for other arches
benefit from them. Probably the packages for other architectures can be
updated with just a rebuild and simple testing, although it can be very
hard to tell, since what hardware is common on which architectures, and
thus which udebs it should go into, is not always easy to determine if
you're not intamately familiar with the architecture. Which is a good
reason to have maintainers who are, instead of me.

Saying that this means I lack responsibility and am only interested in
taking the easy way out is, again, insulting. 

-- 
see shy jo


signature.asc
Description: Digital signature

Re: Debian for desktop - gnome in usnstable/experimantal more stable than in testing ?

[Benjamin Mesing]

Hello,

> > So please disregard my statement against "testing"
> 
[..]
> (In this case, xterm could have had a conflict with your package to
> avoid screwing users over unnoticed; and we could (in future) have added
> a note to the testing scripts to not allow upgrades of xterm until a
> fixed version of packagesearch is also included)
It turned out that what I thought to be a deliberate change of how
arguments are handled in xterm was actually considered to be a bug, and
reported to the BTS [1]. Though xterm made the migration to testing,
because the bug was only of severity normal. So it is nothing wrong with
the testing mechanism, but more likely a wrongly set severity of the
bug.
But here is what I started with: the features in packagesearch relying
on xterm were broken in testing once the version entered it. I was able
to work around this bug in unstable as soon as I realized it, but the
migration of the fixed package to testing was delayed due to the QT
library transition.
The point is humans are making errors (wrongly specified dependencies,
wrong bug priorities,...) and therefore things might break in testing
and the fixes usually take some time to propagate from unstable.
But as I am lacking first hand experience from using testing I don't
know how often it happens in testing, and if this makes testing worse
than unstable -- that's also why I withdraw my statement against using
testing.

Best regards 

Ben

[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=318280


-- 
Please do not send any email to [EMAIL PROTECTED] -- all email not
originating from the mailing list will be deleted. Use the reply to
address instead.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Packages still Depending on xlibs-dev

[Russ Allbery]

Bas Zoetekouw <[EMAIL PROTECTED]> writes:

> Hi Daniel!
> You wrote:

>> Debian QA Group <[EMAIL PROTECTED]>
>>libubit-dev

> Maybe this package should just be removed?  It doesn't have any reverse
> dependencies afaics, and hasn't had a non-QA upload since feb 2004.

Already requested with ftp.debian.org, see Bug#344597.

-- 
Russ Allbery ([EMAIL PROTECTED])   


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug#345977: ITP: polld -- Polling demon

[Hendrik Sattler]

Nathan Poznick wrote:

> Thus spake Roger Leigh:
>> What is the problem this is trying to solve?
>> 
>> If the partition table is being changed, the tool that changed it
>> should issue a BLKRRPART ioctl, like fdisk does for example (see
>> ).
> 
> I have a USB card reader which has 5 different slots for various media.
> If I plug in the card reader and then later insert a CF card, the CF
> card slot's device does not have the partition device created when using
> udev (I have to insert the CF card and then plug in the card reader).  I
> believe this software is created specifically for that purpose - for
> card readers which do not report card insertion / removal to the kernel.

Yes, there are such devices that do no report media changes. However, this 
depends on the device and might be an insufficient support by the usb-storage 
module or a broken card reader device. My one does report the change when I 
pull out the MMC and put it back in. And yes, I use udev (with hal and 
KDE-3.4) and I just tested it.
What model and vendor is this card reader? What chipset does it use? Maybe it 
reports media changes in a way that the usb-storage module does not 
understand, yet...

HS

-- 
Mein GPG-Key ist auf meiner Homepage verfügbar: http://www.hendrik-sattler.de
oder über pgp.net

PingoS - Linux-User helfen Schulen: http://www.pingos.org


pgpXcM3zMNifu.pgp
Description: PGP signature

Re: Bug#345977: ITP: polld -- Polling demon

[Marco d'Itri]

On Jan 04, Nathan Poznick <[EMAIL PROTECTED]> wrote:

> I have a USB card reader which has 5 different slots for various media.
> If I plug in the card reader and then later insert a CF card, the CF
> card slot's device does not have the partition device created when using
> udev (I have to insert the CF card and then plug in the card reader).  I
> believe this software is created specifically for that purpose - for
> card readers which do not report card insertion / removal to the kernel.
OPTIONS+="all_partitions

(Documented in README.Debian and udev(8).)

This program still looks like a bad idea.

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Re: bits from the release team

[Sven Luther]

On Wed, Jan 04, 2006 at 01:11:00PM -0500, Joey Hess wrote:
> Sven Luther wrote:
> > For the installer, sure, but the generation of the d-i kernel .udebs is only
> > marginally of their relevance, and furthermore they don't want the
> > responsability associated with it, and as proof i can show you that joeyh
> > upgraded kernel-wedge and the x86 d-i module udebs, but didn't touch all the
> > other architectures, defaulting it upto the porters, which are the exact 
> > same
> > guys doing the kernel packages. So joeyh and fjp can't have it both way.
> 
> Um, I maintain kernel-wedge and linux-kernel-di-i386*. Not having access
> to every other architecture out there, and with some of the

There is absolutely no need for any architecture access to simply repackage
the modules into an .udeb. Absolutely no need.

> architectures that I do have access to suffering from unaddressed kernel
> bugs (ie #332962) that make my hardware for them useless for testing new
> d-i releases, as well as being limited to modem speeds, makes it
> difficult to maintain anything more.

So, what do you think d-i is so special that it deserve special attention, and
should not fall in the common case of debian kernel bugs ? Maybe you will in
the future start building your own kernels too ? 

It is just damn repackaging, nobody asks you to test anything at all.

> If you take a closer look at the commits in question, my changes were
> limited to kernel-wedge, which means the maintainers for other arches
> benefit from them. Probably the packages for other architectures can be
> updated with just a rebuild and simple testing, although it can be very

this has not been the case in the past, and you should simply have rebuilt and
uploaded them or something.

> hard to tell, since what hardware is common on which architectures, and
> thus which udebs it should go into, is not always easy to determine if

Indeed, which is why it is not needed to duplicate that process twice, once
when the kernel port maintainer choses which config option to include and
which not, and twice when you chose to include those modules in the .udebs or
not.

> you're not intamately familiar with the architecture. Which is a good
> reason to have maintainers who are, instead of me.

None, except for modules concerning the powerpc64 hypervisor and virtual scsi
stuff, of the upgrades that i did for powerpc since the sarge release needed
that kind of intimate knowledge. And all the changes i did, where mirrored on
x86 or something, and i lost maybe 2 hours or so each time time which i could
have spent doing useful work.

> Saying that this means I lack responsibility and am only interested in
> taking the easy way out is, again, insulting. 

No, but you cannot deny that both you and Franz have been ranting against the
porters not taking their duty seriously in the past, and this is one area
where you could make their time more worthwhile, but chose not to.

Friendly,

Sven Luther


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Aptitude question

[Linas Zvirblis]

Jiri Palecek wrote:


Hello,
I have a question on how aptitude decides which packages
to install to satisfy dependencies. I was installing vtk yesterday
and it depends on xlibmesa-gl | libgl1. Aptitude chose to install
xlibmesa-gl which in turn broke my x-window-system-core
metapackage. However, I was able to manually fix it by
using libglu1-xorg for the dependency (and I needed to downgrade it).

How does aptitude decide which one to choose? Shouldn't it
prefer to do something that won't break other packages? Or should
it ask the user for help?


First of all, such questions should go to debian-user mailing list. 
Debian-devel is for internal development of Debian.


As for your problem, you must provide way more information than just "it 
does not work" in order to get help. There are at least five different 
versions of aptitude you could be using on whatever version of Debian 
you use. Most of us cannot read minds, especially over the Internet.


Anyway, installing vtk-tcl (that depends on xlibmesa-gl | libgl1 and 
libglu1-xorg | libglu1) on my box did not break anything.



--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Aptitude question

[Jiri Palecek]

Hello,

I have a question on how aptitude decides which packages
to install to satisfy dependencies. I was installing vtk yesterday
and it depends on xlibmesa-gl | libgl1. Aptitude chose to install
xlibmesa-gl which in turn broke my x-window-system-core
metapackage. However, I was able to manually fix it by
using libglu1-xorg for the dependency (and I needed to downgrade it).

How does aptitude decide which one to choose? Shouldn't it
prefer to do something that won't break other packages? Or should
it ask the user for help?

Jiri Palecek
__
Verschicken Sie romantische, coole und witzige Bilder per SMS!
Jetzt bei WEB.DE FreeMail: http://f.web.de/?mc=021193


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: How to Increase Contributions from Volunteers

[Thomas Hood]

Anthony Towns:
> Anyway, the real point of replying was for me to have some fun playing
> (what I'll hereby dub) the false dichotomy game. That's where you take
> a set of contradictory statements, and setup reasonable scenarios where,
> in fact, both alternatives are true simultaneously.

I'd call it the "obscure the point game", because the pairs of statements
were meant to illustrate a difference in attitude, not a set of absolute
contradictions.  But I think you know that.  Because you are really playing
another game, which I'll dub "the innuendo game".
-- 
Thomas Hood


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: How to Increase Contributions from Volunteers

[Henning Makholm]

Scripsit Manoj Srivastava <[EMAIL PROTECTED]>

> People who do not want to undergo that process can just help
>  out current developers, fix bugs, send patches, etc.

Why are you then disagreeing with Andreas when he said that we should
make the possibility of doing this more visible?

>  I am merely vocing objections to lowering the bar for people who
>  are responsible for Debian packages, and can thus run code as root
>  on my machine.

How on earth do you manage to interpret "promote the easy entry points
to contributing to debian more prominently" as "lowering the bar"?

-- 
Henning Makholm  "Wir kommen nun ans Ziel unserer Ausführungen."


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: How to Increase Contributions from Volunteers

[Anthony Towns]

On Wed, Jan 04, 2006 at 07:41:38PM +0100, Thomas Hood wrote:
> Anthony Towns:
> > Anyway, the real point of replying was for me to have some fun playing
> > (what I'll hereby dub) the false dichotomy game. That's where you take
> > a set of contradictory statements, and setup reasonable scenarios where,
> > in fact, both alternatives are true simultaneously.
> I'd call it the "obscure the point game", because the pairs of statements
> were meant to illustrate a difference in attitude, not a set of absolute
> contradictions. 

You can call it whatever you like. The art of compromise and consensus
building is the art of finding something that achieves apparently
conflicting goals simultaneously.

> But I think you know that.  Because you are really playing
> another game, which I'll dub "the innuendo game".

Cheers,
aj



signature.asc
Description: Digital signature

outdated links on http://www.us.debian.org/doc/

[kamaraju kusumanchi]

I was reading http://www.us.debian.org/doc/ and found a link to 
"Installation guide for Debian 2.2" (at the end of the page). I am 
thinking with sarge release this is somewhat outdated and might send 
wrong hints to the end user browsing the website. I think this link 
should be removed. Any ideas?


thanks
raju


--
Kamaraju S Kusumanchi
http://www.people.cornell.edu/pages/kk288/
http://malayamaarutham.blogspot.com/


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Size matters. Debian binary package stats

[Thomas Bushnell BSG]

Goswin von Brederlow <[EMAIL PROTECTED]> writes:

> Spare disk space isn't available to add amd64 to mirrors.
> Spare bandwith isn't available to add amd64 to mirrors.

I see.  Can we please have the numbers?  Exactly how much disk space
is needed?  Perhaps we can simply go ahead and buy more disks for our
machines.

Mirrors that don't want to carry the additional arch shouldn't have
to; this should be easy to arrange.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Experiment: poll on "switching to vim-tiny for standard vi?"

[Thomas Bushnell BSG]

Joey Hess <[EMAIL PROTECTED]> writes:

> Oh, come on. vim-tiny entered the archive this week. The fact that we
> have some slow buildds and ports like hurd-i386 that are perennially
> behind is irrelevant to this discussion unless you can point to a build
> failure log.

Maybe we shouldn't switch the standard vi to a package which has only
been in the archive for one week?


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Thoughts on Debian quality, including automated testing

[Ola Lundqvist]

Hello

On Wed, Dec 21, 2005 at 12:23:32PM +0100, Thomas Hood wrote:
> First, thanks to Lars for drawing our attention to an important topic
> and for taking an initiative that is long overdue.
> 
> Lars, I agree fully with what you say.  When it comes to team
> maintenance I would go even further than you do.  You say:
> 
> > Mandatory teams for packages seems ridiculous to me. 
> > Lots of packages are so small that having to arrange a 
> > team for them, even if it is only the effort to set up 
> > and subscribe to a team mailing list, is wasteful. Not 
> > everyone likes to work in a close team, either, and we 
> > shouldn't exclude them.
> 
> I don't think that it is ridiculous to require that every package have a
> team behind it---i.e., at least two maintainers.  First, if someone can't
> find ONE other person willing to be named as a co-maintainer of a given
> package then I would seriously doubt that that package (or that person)
> is an asset to Debian.  Second, putting packages in the custody of a

It really depend on what you mean with an asset. Just because a package
do not have a big userbase do not say that it is unimportant.

To find someone to be named as co-maintainer is quite easy. It is _much_
harder to find a real co-maintainer, that will actually make some work.

If you mean that every package should have at least one other person
that is willing to upload critical fixes, all packages already have that
as all maintainers (or very many of them at least) will NMU packages
if they have RC bugs with a patch... :)

> team makes it easy for a tired maintainer to relinquish control.  If the
> team works via an alioth project then there are many benefits. Code is
> kept under version control and thus backed up; the change history can be
> easily viewed by anyone; the mailing list becomes an easily browsed
> history of package development.  Team maintainership is working very
> well for some other distributions.
> 
> I would support requiring team maintainership because TM will be
> beneficial in almost all cases and making it a requirement it cuts off a
> lot of useless discussion.  There are several packages in Debian that are

I do not agree, obviously. :)

...CUT...

Regards,

// Ola

-- 
 - Ola Lundqvist ---
/  [EMAIL PROTECTED] Annebergsslingan 37  \
|  [EMAIL PROTECTED] 654 65 KARLSTAD  |
|  +46 (0)54-10 14 30  +46 (0)70-332 1551   |
|  http://www.opal.dhs.org UIN/icq: 4912500 |
\  gpg/f.p.: 7090 A92B 18FE 7994 0C36  4FE4 18A1 B1CF 0FE5 3DD9 /
 ---


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: outdated links on http://www.us.debian.org/doc/

[Frans Pop]

(Moving this thread to d-www where this is more on-topic.)

On Wednesday 04 January 2006 20:58, kamaraju kusumanchi wrote:
> I was reading http://www.us.debian.org/doc/ and found a link to
> "Installation guide for Debian 2.2" (at the end of the page). I am
> thinking with sarge release this is somewhat outdated and might send
> wrong hints to the end user browsing the website. I think this link
> should be removed. Any ideas?

Yes, I agree. Although the link does contain some nice information, most 
of it is clearly obsolete.

I'd like to propose deleting the entire line, unless ppl feel linking to 
the Installation Howto [1] (which is part of the Installation Guide) 
instead would be useful.

Cheers,
FJP

[1] http://www.debian.org/releases/stable/i386/apa.html


pgpHHrS6Gm4Qe.pgp
Description: PGP signature

Fwd: Bug#344758: init.d script should create /var/run/dirmngr

[Peter Eisentraut]

What do you think about this request?  It seems reasonable, but I think if 
this should be supported, there ought to be a general policy (formal or 
informal) on it because I think many other init scripts will suffer from 
similar problems.

--  Forwarded message  --

Subject: Bug#344758: init.d script should create /var/run/dirmngr
Date: Sonntag, 25. Dezember 2005 18:22
From: System Administrator <[EMAIL PROTECTED]>
To: Debian Bug Tracking System <[EMAIL PROTECTED]>

Package: dirmngr
Version: 0.9.3-1
Severity: normal

The script should create /var/run/dirmngr to allow users to map their
/var/run to a temporary filesystem like tmpfs. Thanks.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug#345977: ITP: polld -- Polling demon

[Michal Čihař]

Hi

On Wed, 4 Jan 2006 19:33:26 +0100
[EMAIL PROTECTED] (Marco d'Itri) wrote:

> On Jan 04, Nathan Poznick <[EMAIL PROTECTED]> wrote:
> 
> > I have a USB card reader which has 5 different slots for various media.
> > If I plug in the card reader and then later insert a CF card, the CF
> > card slot's device does not have the partition device created when using
> > udev (I have to insert the CF card and then plug in the card reader).  I
> > believe this software is created specifically for that purpose - for
> > card readers which do not report card insertion / removal to the kernel.
> OPTIONS+="all_partitions
> 
> (Documented in README.Debian and udev(8).)

I know about this. This pollutes my /dev with many files, forcing to
rescan device makes appear only partitions which exist.

> This program still looks like a bad idea.

Find better way to do same thing. Card reader seems to not report card
changes at all.

I'm not on debian-devel, please cc me.

-- 
Michal Čihař | http://cihar.com


signature.asc
Description: PGP signature

APT public key updates?

[Petter Reinholdtsen]

When I try to upgrade one of my machines running testing, I get a
warning about a missing public key:

  [...]
  W: GPG error: http://ftp.no.debian.org testing Release: The
following signatures couldn't be verified because the public key is
not available: NO_PUBKEY 010908312D230C5F
  W: You may want to run apt-get update to correct these problems
  [...]
  Do you want to continue? [Y/n/?]
  WARNING: untrusted versions of the following packages will be installed!

  Untrusted packages could compromise your system's security.
  You should only proceed with the installation if you are certain
  that this is what you want to do.
  [...]

I guess this is not how every GPG key change for the archive is
supposed to be handled, as I would expect key updates to happen mostly
automatic.  Where can I find information on what went wrong with my
installation, and what the correct procedure is to fix it when this
problem arises.  I'm glad it does not happen to several hundred
production machines, and just my test machine.

I worked around the problem using this formula, but expect there must
be a more sensible way to handle public key updates:

  gpg --recv-key 010908312D230C5F && gpg -a --export 2D230C5F | apt-key add -


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: APT public key updates?

[Daniel Leidert]

Am Donnerstag, den 05.01.2006, 00:03 +0100 schrieb Petter Reinholdtsen:
> When I try to upgrade one of my machines running testing, I get a
> warning about a missing public key:
> 
>   [...]
>   W: GPG error: http://ftp.no.debian.org testing Release: The
> following signatures couldn't be verified because the public key is
> not available: NO_PUBKEY 010908312D230C5F
[snip]

See
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=345823
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=345891
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=345956
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=346002

Regards, Daniel


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

What's the best directory to put a local Debian repository?

[Maurits van Rees]

Hi,

I'm wondering what the best place is to put a local Debian package
repository.  Directories that spring to mind are:

- /var/www/debian

  This eases access via e.g. Apache (though a soft link here to
  another dir would work fine as well of course)

- /srv/debian

  According to the Filesystem Hierarchy Standard the /src dir is for
  Data for services provided by this system, which seems to fit the
  bill.

- /var/local/debian

  It's variable, it's local, it's about Debian.  Simple.


It probably doesn't really matter, but is there a canonical directory
for this?

Thanks,

P.S.  In case you're wondering: this is my first post here.  I am
subscribed.

-- 
Maurits van Rees | http://maurits.vanrees.org/ [NL]
Work | http://zestsoftware.nl/
   GnuPG key | http://maurits.vanrees.org/var/gpgkey.asc
"Do only what only you can do." --- Edsger Wybe Dijkstra


signature.asc
Description: Digital signature

Re: Size matters. Debian binary package stats

[Christian Leber]

On Sun, Dec 18, 2005 at 08:31:26PM +0100, Florian Weimer wrote:
> > Afaict from the webpage 7zip (LZMA) is quite a bit slower bzip2. -
> > Have you perhaps run some benchmarks?
> Memory use during decompression would be interesting, too.

For pure lzma it isn't really bad, it's about 100kb + directory_size and
this is usually 8 MB (that is a sane value), but smaller directory
sizes may be used as well.

Some data discussion, also for the speed issue:

(user time only)
compression of libgcj6 (17612800 uncompressed), the first file i found
that is big enough for usefull data

gzip-  7.5 sec - 5118403
bzip2   - 16.9 sec - 5039522
lzma 8MB (-a2)  - 53.8 sec - 3643734
lzma 2MB (-a2)  - 50.3 sec - 3648493
lzma 1MB (-a2)  - 48.1 sec - 3675183
lzma 1MB (-a1)  - 41.1 sec - 3707349
lzma 1MB (-a0)  - 23.5 sec - 3985219
lzma 512k(-a0)  - 22.6 sec - 3994574
lzma 2MB (-a0)  - 26.5 sec - 3979074

decompression:
  Memory usage about
gzip -  0.2 sec -   no idea, but few
bzip2-  3.2 sec -   3700 kb
lzma 8MB -  0.8 sec -   8200 kb
lzma 2MB -  0.8 sec -   2150 kb
lzma 1MB -  0.8 sec -   1120 kb
lzma 512k-  0.8 sec -   620 kb


In the end adding lzma to dpkg can't harm, it's just a small patch and
has no external requierements, code size just grows like 12 kb or
something.

Cheers,
Christian

-- 
  "Omnis enim res, quae dando non deficit, dum habetur et non datur,
   nondum habetur, quomodo habenda est."   (Aurelius Augustinus)
  Translation: 


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

ITP

[campanoni simone]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi, i'm campanoni simone and i'm working on a project named WSS (World
Simulator Server); i'd like that this project will be added in a
debian distribution.
The reasons on why i would like that are mainly three:
~- i'd like to think that the wss project will be useful for other
than me  
~- i'm using the wss project and i'm using a debian distribution so

adding it in debian will get my system coerence with the official one
~ - i'd like to try to mantain the wss packet (to learn to mantein
a debian packet)

The project can be found (in tar.bz2 and in deb packet) at

http://xan.homelinux.org/wakeup/projects/wss/wss.php

The project is a simulator of some physics effects like temperature,
water ecc... ; the focus of WSS is not on the accuracy on the
simulation (very very poor :-) ), but on making a world where anybody
can test his software agents for IA reasons.

Thank you in advance,
~campanoni simone

- --
~  `$' $' 
~   $  $  _

~  ,d$$$g$  ,d$$$b. $,d$$$b`$' g$b $,d$$b
~  ,$P'  `$ ,$P' `Y$ $$'  `$ $  "'   `$ $$' `$
~  $$ $ $$g$ $ $ $ ,$P""  $ $$
~  `$g. ,$$ `$$._ _. $ _,g$P $ `$b. ,$$ $$
~   `Y$$P'$. `YP $$$P"' ,$. `Y$$P'$ $.  ,$.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFDvFpEnmCeoQ14vqQRAt01AJ43g6XJwkT2fyGg51wmxdVfWJwovQCcD7h3
7THPzXrdwDIO//PsQOwhMLI=
=cUPD
-END PGP SIGNATURE-


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: What's the best directory to put a local Debian repository?

[Russ Allbery]

Maurits van Rees <[EMAIL PROTECTED]> writes:

> I'm wondering what the best place is to put a local Debian package
> repository.  Directories that spring to mind are:

[...]

> - /srv/debian

>   According to the Filesystem Hierarchy Standard the /src dir is for
>   Data for services provided by this system, which seems to fit the
>   bill.

I vote for this.  At Stanford, we're slowly trying to migrate local data
for services running on the machine into /srv.  It's the Right Thing from
the FHS perspective so far as I can tell.

-- 
Russ Allbery ([EMAIL PROTECTED])   


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: How to Increase Contributions from Volunteers

[Peter Samuelson]

[Roger Leigh]
> In the case of someone who attaches a patch to a bug report, I think
> getting a mention in the Debian (or upstream) ChangeLog is
> sufficient.

Indeed, back in the days when reporting a bug and attaching a patch was
all I was willing to spend time doing, I thought a mention in the
debian changelog was exactly the right amount of encouragement.


signature.asc
Description: Digital signature

Re: Fwd: Bug#344758: init.d script should create /var/run/dirmngr

[Peter Samuelson]

[Peter Eisentraut]
> What do you think about this request?  It seems reasonable, but I
> think if this should be supported, there ought to be a general policy
> (formal or informal) on it because I think many other init scripts
> will suffer from similar problems.

This issue was mentioned in the /run discussion we just had on this
list.  I'm in favor of forcing all init scripts to mkdir -p
/var/run/whatever-they-will-need; it's not like this is hard to do.
mkdir -p even handles "directory already exists" sanely (i.e., silently
and without error).


signature.asc
Description: Digital signature

Re: Fwd: Bug#344758: init.d script should create /var/run/dirmngr

[Henrique de Moraes Holschuh]

On Wed, 04 Jan 2006, Peter Samuelson wrote:
> [Peter Eisentraut]
> > What do you think about this request?  It seems reasonable, but I

[...]
> This issue was mentioned in the /run discussion we just had on this
> list.  I'm in favor of forcing all init scripts to mkdir -p



Do it.  We are *heavly* considering support for ephemeral /var/run (which is
orthogonal to /run or anything else in that topic), so you might as well do
it now and make your user happy.  A lot of other packages already support
ephemeral /var/run.

BUT, if you do, don't ship /var/run inside the deb.

> /var/run/whatever-they-will-need; it's not like this is hard to do.
> mkdir -p even handles "directory already exists" sanely (i.e., silently
> and without error).

Do remember to bang out gracefully with an error if you need to chown and
chmod that directory (e.g. for a daemon that uses a system user created in
postinst), and that fails for some reason.

-- 
  "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 [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Debian for desktop - gnome in usnstable/experimantal more stable than in testing ?

[Steve Langasek]

On Wed, Jan 04, 2006 at 01:22:57PM -0500, Benjamin Mesing wrote:
> > > So please disregard my statement against "testing"

> > (In this case, xterm could have had a conflict with your package to
> > avoid screwing users over unnoticed; and we could (in future) have added
> > a note to the testing scripts to not allow upgrades of xterm until a
> > fixed version of packagesearch is also included)
> It turned out that what I thought to be a deliberate change of how
> arguments are handled in xterm was actually considered to be a bug, and
> reported to the BTS [1]. Though xterm made the migration to testing,
> because the bug was only of severity normal. So it is nothing wrong with
> the testing mechanism, but more likely a wrongly set severity of the
> bug.
> But here is what I started with: the features in packagesearch relying
> on xterm were broken in testing once the version entered it. I was able
> to work around this bug in unstable as soon as I realized it, but the
> migration of the fixed package to testing was delayed due to the QT
> library transition.

This same Qt library transition would have prevented some number of users of
unstable from installing a fixed version of packagesearch during that same
period.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
[EMAIL PROTECTED]   http://www.debian.org/


signature.asc
Description: Digital signature

D-I team meeting on Saturday January 21st 17:00UTC

[Christian Perrier]

The monthly Debian Installer team meeting which was initially
scheduled for January 14th is reported to January 21st, as several D-I
developers will attend the "Extremadura session" about the graphical
installer development
(http://wiki.debian.org/WorkSessionsExtremadura).

Topics for the meeting are still to be completed
(http://wiki.debian.org/DebianInstallerMeetings) but it's very likely
that the main topic will be the preparation  for the Etch beta2
release of the installer.

(this mail is CC'ed to -devel in an attempt to draw  a few more
attention for these monthly meetings, especially from people who used
to be active in the D-I development in the past..:-)))

-- 




-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Fwd: Bug#344758: init.d script should create /var/run/dirmngr

[Steve Langasek]

On Wed, Jan 04, 2006 at 10:43:57PM -0200, Henrique de Moraes Holschuh wrote:
> On Wed, 04 Jan 2006, Peter Samuelson wrote:
> > [Peter Eisentraut]
> > > What do you think about this request?  It seems reasonable, but I

> [...]
> > This issue was mentioned in the /run discussion we just had on this
> > list.  I'm in favor of forcing all init scripts to mkdir -p

> 

> Do it.  We are *heavly* considering support for ephemeral /var/run (which is
> orthogonal to /run or anything else in that topic), so you might as well do
> it now and make your user happy.  A lot of other packages already support
> ephemeral /var/run.

> BUT, if you do, don't ship /var/run inside the deb.

Why?

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
[EMAIL PROTECTED]   http://www.debian.org/


signature.asc
Description: Digital signature