Re: Depends vs. Recommends

[Frank Küster]

Jens Peter Secher <[EMAIL PROTECTED]> wrote:

> Adam Borowski <[EMAIL PROTECTED]> writes:
>
>> On Sun, Jul 16, 2006 at 10:11:41AM +0200, Thijs Kinkhorst wrote:
>>> 
>>> I agree that that is a common type of file to recover, so that would
>>> make it more appropriate to Recommend cpio rather than Suggest.
>>
>> "a common type"?  Come on, that's not just "common", it's "a vast
>> majority of cases".  And, a hard Depend on a small priority=important
>> package is not a big burden -- what about just having a dependency
>> without the comment?
>
> No.
>
> And the reason can be found in Policy section 7.2:
>
[...]
> The Depends field should be used if the depended-on package is
> required for the depending package to provide a significant
> amount of functionality.
>
> The Depends field should also be used if the postinst, prerm or
> postrm scripts require the package to be present in order to
> run. Note, however, that the postrm cannot rely on any
> non-essential packages to be present during the purge phase.
[...]
>
> The dependency system is used to make sure things don't break on the
> _system_ level.  

I don't agree.  This "break on the system level" only relates to the
second paragraph I quoted.  The first one is also a reason for a
Depends.  If this other package is needed for the core functionality,
than it should be depended on.

> To ease upgrades, transitions, etc., dependencies
> (Depends) should be kept to the absolute minimum.

There's always a tradeoff:  The easiest system to upgrade is one that
runs, but is barely usable for anything...

Regards, Frank
-- 
Frank Küster
Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich
Debian Developer (teTeX/TeXLive)

Re: Depends vs. Recommends

[Helmut Wollmersdorfer]

Frank Küster wrote:

Jens Peter Secher <[EMAIL PROTECTED]> wrote:



To ease upgrades, transitions, etc., dependencies
(Depends) should be kept to the absolute minimum.



There's always a tradeoff:  The easiest system to upgrade is one that
runs, but is barely usable for anything...


'usable' - yes, it's a usability problem.

In aptitude you can use the command line options

  -R, --without-recommends
  -r, --with-recommends

but I am missing

   --without-suggests
   --with-suggests

IMHO these options give you the choice. I disagree to change 
'recommends' to 'depends', because it should be the users choice to 
install 'minimal' or 'full', but this choice should be as convenient as 
possible.


Nowadays it is more or less a standard in 'other' (package or OS) 
installers, e.g. Win, Office, Suse, Fedora, to let the user choose between


- minimum  ~ 'depends'
- standard ~ 'recommends'
- full ~ 'suggests'

Also a mode called 'expert' or 'customized' is provided, which allows 
navigation through package/feature relationships.


I am missing this very useful, commonly understandable standard in d-i, 
g-i, tasksel etc.


Helmut Wllmersdorfer


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

Re: Getting the buildds to notice new architectures in a package

[Wouter Verhelst]

On Mon, Jul 17, 2006 at 05:53:25AM +0200, Goswin von Brederlow wrote:
> The buildd package could just be a central hub where two or three
> knowlegable people sift through the bug reports and then distribute it
> to the affected/responsible person.

Who would you suggest would do that? I know it's not going to be me.

-- 
Fun will now commence
  -- Seven Of Nine, "Ashes to Ashes", stardate 53679.4


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

Re: Challenge: Binary free uploading

[Wouter Verhelst]

On Mon, Jul 17, 2006 at 03:42:18PM +1000, Anthony Towns wrote:
> On Sun, Jul 16, 2006 at 08:14:48PM +0200, Wouter Verhelst wrote:
> > For starters, we'd need a *lot* of hardware to be able to do all these
> > builds. Many of them will fail, because there *will* be people who will
> > neglect to test their builds, and they will hog the machine so that
> > other people (who do test properly) have to wait a long time for their
> > build to happen.
> 
> As it stands, I don't think this would be a shared service; but rather
> something people setup on their own -- so you edit on your laptop, commit
> to your server, and have the build happen remotely so you don't hear the
> disk grind, or have your load average increase while you're busy trying
> to play armagetron... It could be shared for team maintained things like
> the X packages, but at least initially, I wouldn't think that would be
> worth worrying about.

Oh, that way. Hrm, that might work.

> That's also why I lean towards pbuilder instead of sbuild -- sbuild is
> great for building lots of packages continually; but pbuilder's better for
> setting up quickly and easily without having to put much thought into it.

Don't have much of an argument there.

> My guess would be that it ought to be possible to hack up a pretty simple
> shell script that does this usefully, then build on it from there.

Actually, I don't think it would be very hard to modify buildd to be
able to run pbuilder instead of sbuild. I would have to check, though.

(and no, I'm not volunteering to do this -- sbuild works okayish for me,
and I have more than enough to do as it is :)

-- 
Fun will now commence
  -- Seven Of Nine, "Ashes to Ashes", stardate 53679.4


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

Re: Depends vs. Recommends

[Frank Küster]

Helmut Wollmersdorfer <[EMAIL PROTECTED]> wrote:

> IMHO these options give you the choice. I disagree to change
> recommends' to 'depends', because it should be the users choice to
> install 'minimal' or 'full', but this choice should be as convenient
> as possible.
>
> Nowadays it is more or less a standard in 'other' (package or OS)
> installers, e.g. Win, Office, Suse, Fedora, to let the user choose
> between
>
> - minimum  ~ 'depends'
> - standard ~ 'recommends'
> - full ~ 'suggests'
>
> Also a mode called 'expert' or 'customized' is provided, which allows
> navigation through package/feature relationships.

I think this is a different thing.  It might be a worthwile goal to
introduce something like this in Debian.  But currently "Depends" means
"everything that is needed for the core parts of the functionality" (or
"significant functionality" as the Policy puts it.  

In many cases this includes more packages than are required for the
installation to succeed.  And IMO it includes everything that is needed
to at least get a decent error message from the executables that won't
work without installing additional packages.  Imagine a package that
includes scripts in Perl or Python, it does a sensible thing even
without them, but it isn't feasible or doesn't make sense to write shell
wrapper scripts with "please install python" error messages for all of
them.  In this case, I think the package should depend on the scripting
language, and not require the user to look into README.Debian to learn
what he has to do to get rid of

bash: /home/frank/bin/testnointerpreter: /usr/bin/pearl: bad interpreter: No 
such file or directory

which might well be hidden if the script is invoked by some graphical
frontend. 

Regards, Frank
-- 
Frank Küster
Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich
Debian Developer (teTeX/TeXLive)

Re: Challenge: Binary free uploading

[Adeodato Simó]

> Hi all,

Hi, I wanted to chip in and share a couple thoughts on the matter,
namely:

  (a) why (at the moment) "Debian's buildd network" is not an area
  particularly suited to get improved by "looking at what Ubuntu is
  doing" (in other words, why little Ubuntu does there can be directly
  imported into Debian)

  (b) how the Ubuntu NoMoreSourcePackages initiative linked by Anthony
  is way more than "zomsg, look, our i386 builddz can `bzr get` and
  don't pass -b to dpkg-buildpackage"

 * * *

Let's start with (a). For good or bad, the fact is that in Debian,
ensuring that uploads have received a fair amount of testing and human
supervision, _both_ in terms that the source package is correct and
builds correctly, and that the binary packages do work properly, is
still a big concern.

Whenever changes like "binary-less uploads" or "autosigning buildds", or
similar, get proposed, the above concern is normally enough to stop
them. For example, if you mention in -devel the idea "maintainer does
not generate the source package, but buildd does from a VCS", a big part
of the discussion goes to ensuring the change would not negatively
affect to the amount of testing the packages get:

> * Anthony Towns [Sun, 16 Jul 2006 16:47:12 +1000]:

> and if the build was successful, make the .changes file, the
> source and the binary packages available, so that they can be checked by
^^^
> hand, and uploaded to the archive.

> * martin f krafft [Sun, 16 Jul 2006 14:24:19 +0200]:

> it's just too easy to sign and send back a changes file when you are
> currently too busy with other things.

> Thus, my idea was to require a certain number of certificates to be
> attached to the changes file, which prove that the source has been

> tested. E.g. lintian could issue a certificate just as well as
  ^^

> * Stephen Gran [Mon, 17 Jul 2006 00:00:10 +0100]:

> Why not just require binary uploads, and then chuck the binary away?
> Then we are where we are today (someone managed to get the thing to
  ^^^
> build at least once), but all debs are built from source on the buildd's.
  ^^^
 
And, of course (with penalties, even!):

> * Bernhard R. Link [Sun, 16 Jul 2006 11:54:32 +0200]:

> I think this should have some check reading the download-logs and
> refuse the upload (and perhaps also delete all built files and
> blacklisting the requestor for a month), if the generated .deb files
> were not downloaded or the signed changes sent in within some absurd
> short time making it inplausible the build was actually checked.
 
> Something like a quarter of an hour, I'd suggest.

> On a second thought, perhaps better half an hour and also checking the
   ^
> .diff.gz was downloaded...
  ^^^

This is why, IMHO and while the above does not change, maybe it's just
more efficient to make improvements to Debian's own buildd network by
conceiving them ourselves, by just thinking on what we need from buildds
so that they adapt to our needs better.

But also, I'm really very curious (and would welcome insight from any
Ubuntu people reading this) how the above mentioned concerns for
"ensuring a minimum amount of testing" are addressed in Ubuntu. If I let
my creative mood trump in, I can think of a couple discourses that would
explain:

  (1) “if you think carefully, in the very end a lack of testing only
  hurts the autobuilders, whilst results in saved time for the
  maintainers in the common case. And since in Ubuntu we have the
  resources to increase the number of autobuilders, but our number
  of maintainers is low...”

  (2) “uploading source & binaries is sooo 20th century, mate.”

 * * *

Now for the (maybe more interesting) (b). Seems like after Antony posted
the link to https://wiki.ubuntu.com/NoMoreSourcePackages, the discussion
has mostly centered around the "buildds that speak to VCS" part of the
spec, but I'd like to draw your attention into a couple points that are,
IMHO, worth having spelled out (and of which "builddz talk VCS" is just
a by-product of):

  * what it really says there is "we find that the source package hinders
our development model, so we plan on freeing our maintainers of that
burden [pretty much as they freed them of the 'final binary packages
are built in a clean environment provided by the maintainer' concept],
and let they exist as an internal buildd component only".

(In the paragraph above, "our development model" means "that where
everybody can upload any package". But note that, obviously, that
while they can say "everybody can play", 

Re: release update: Etch 4.0, Blockers and Goals, Arch status, kernel 2.4, etc

[Török Edvin]

On Mo Jul 17 11:15:28 UTC 2006, Marc Brockschmidt <[EMAIL PROTECTED]> wrote:

- - SELinux support

What are the plans for SELinux support?

Best regards,
Edwin


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

Re: Challenge: Binary free uploading

[Bernhard R. Link]

* Adeodato Sim?? <[EMAIL PROTECTED]> [060717 15:11]:
> But also, I'm really very curious (and would welcome insight from any
> Ubuntu people reading this) how the above mentioned concerns for
> "ensuring a minimum amount of testing" are addressed in Ubuntu.

Actually that "minimum amount of testing" is one of my biggest concerns
with ubuntu. Of course I'm biased because I do not care about Ubuntu and
only get in touch with it, as people come to me as the "local person you
can ask when something does not work with your Debian system" also with
their Ubuntu problems, so I only see the worst cases.

Take a look at https://launchpad.net/distros/ubuntu/+source/xdm/+bug/2461
for example. From my POV someone took a new version and uploaded it but
most likely never tested it, because it simply cannot work without the
missing part, it does not start, does not run, does nothing. And such
a package even entered a release. (I've never looked at a launchpad
before so I may misparse it, the person coming to me with the problem
at least claimed it was a released version he used)

That's no big problem when you have a majority only target and people
can always switch back to Debian once they realize that they - like
anyone else - are a minority. But once the game is no longer
"a small group of people cope with a large volume of stuff and make
sure the things journalists look at work properly" but "every package
has a maintainer looking after it" there should be proper testing
procedures. And when there are no proper testing procedures, at least
the procedures should be choosen to not discourage testing. 

Hochachtungsvoll,
  Bernhard R. Link


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

Processed: Unblocking, this bugs belong to stable and old-stable

[Debian Bug Tracking System]

Processing commands for [EMAIL PROTECTED]:

> unblock 322762 by 332303
Bug#322762: /usr/doc still exists (transition tracking bug)
Was blocked by: 189856 190020 203278 254800 254913 254924 255590 302504 319726 
320084 320103 321926 322749 322769 322772 322776 322778 322779 322781 322782 
322783 322784 322785 322786 322787 322788 322789 322790 322791 322792 322793 
322794 322795 322797 322798 322799 322800 322801 322803 322804 322805 322806 
322807 322808 322809 322810 322811 322812 322813 322814 322815 322816 322817 
322818 322819 322820 322828 322829 322830 322831 322832 322833 322834 322835 
322837 322838 322839 332303 352893 352894 353569 355341 359358 359359 359360 
359361 359362 359363 359364 359365 359366 359367 359368 359369 359370 359371 
359372 359374 359375 359376 359377 359378 359379 359380 359381 359382 359383 
359384 359385 359386 359387 359388 359389 359390 359391 359392 359393 359394 
359395 359396 359397 359398 359399 359400 359401 359402 359403 359404 359405 
359406 359407 359408 359409 359410 359411 359412 359413 359414 359415 359416 
359417 359418 359419 359420 359421 359422 359423 359424 359425 359426 359427 
359428 359429 359430 359431 359432 359433 359434 359435 359436 359437 359439 
359440 359441 359442 359443 359444 359445 359446 359447 359448 359449 359450 
359451 359452 359453 359454 359455 359456 359457 359458 359459 359460 359461 
359462 359463 359464 359465 359466 359467 359468 359469 359470 359471 359472 
359473 359474 359475 359476 359477 359478 359479 359480 359481 359482 359483 
359484 359485 359486 359487 359488 359489 359490 359491 359492 359493 359494 
359495 359496 359497 359498 359499 359500 359501 359502 359503 359504 359505 
359506 359507 359508 359509 359510 359511 359512 359513 359514 359515 359516 
359517 359518 359519 359520 359521 359522 359523 359524 359526 359527 359528 
359529 359530 359531 359532 359533 359534 359535 359536 359537 359538 359539 
359540 359541 359542 359543 359544 359545 359546 359547 359548 359549 359550 
359551 359552 359553 359554 359555 359556 359557 359558 359559 359560 359561 
359562 359563 359564 359565 359566 359567 359568 359569 359570 359571 359572 
359573 359574 359575 359576 359577 359578 359579 359580 359581 359582 359583 
359584 359585 359586 359587 359588 359589 359590 359591 359592 359593 359594 
359595 359596 359597 359598 359599 359600 359601 359602 359603 359604 359605 
359606 359607 359608 359609 359610 359611 359612
Blocking bugs of 322762 removed: 332303, 359404

> unblock 322762 by 359360
Bug#322762: /usr/doc still exists (transition tracking bug)
Was blocked by: 189856 190020 203278 254800 254913 254924 255590 302504 319726 
320084 320103 321926 322749 322769 322772 322776 322778 322779 322781 322782 
322783 322784 322785 322786 322787 322788 322789 322790 322791 322792 322793 
322794 322795 322797 322798 322799 322800 322801 322803 322804 322805 322806 
322807 322808 322809 322810 322811 322812 322813 322814 322815 322816 322817 
322818 322819 322820 322828 322829 322830 322831 322832 322833 322834 322835 
322837 322838 322839 352893 352894 353569 355341 359358 359359 359360 359361 
359362 359363 359364 359365 359366 359367 359368 359369 359370 359371 359372 
359374 359375 359376 359377 359378 359379 359380 359381 359382 359383 359384 
359385 359386 359387 359388 359389 359390 359391 359392 359393 359394 359395 
359396 359397 359398 359399 359400 359401 359402 359403 359405 359406 359407 
359408 359409 359410 359411 359412 359413 359414 359415 359416 359417 359418 
359419 359420 359421 359422 359423 359424 359425 359426 359427 359428 359429 
359430 359431 359432 359433 359434 359435 359436 359437 359439 359440 359441 
359442 359443 359444 359445 359446 359447 359448 359449 359450 359451 359452 
359453 359454 359455 359456 359457 359458 359459 359460 359461 359462 359463 
359464 359465 359466 359467 359468 359469 359470 359471 359472 359473 359474 
359475 359476 359477 359478 359479 359480 359481 359482 359483 359484 359485 
359486 359487 359488 359489 359490 359491 359492 359493 359494 359495 359496 
359497 359498 359499 359500 359501 359502 359503 359504 359505 359506 359507 
359508 359509 359510 359511 359512 359513 359514 359515 359516 359517 359518 
359519 359520 359521 359522 359523 359524 359526 359527 359528 359529 359530 
359531 359532 359533 359534 359535 359536 359537 359538 359539 359540 359541 
359542 359543 359544 359545 359546 359547 359548 359549 359550 359551 359552 
359553 359554 359555 359556 359557 359558 359559 359560 359561 359562 359563 
359564 359565 359566 359567 359568 359569 359570 359571 359572 359573 359574 
359575 359576 359577 359578 359579 359580 359581 359582 359583 359584 359585 
359586 359587 359588 359589 359590 359591 359592 359593 359594 359595 359596 
359597 359598 359599 359600 359601 359602 359603 359604 359605 359606 359607 
359608 359609 359610 359611 359612
Blocking bugs of 322762 removed: 359360

> unblock 322762 by 359397
Bug#322762: /usr/doc still exists (transition tracki

Bug#378568: ITP: courieruserinfo -- Retrieve courier user account information

[Charles Fry]

Package: wnpp
Severity: wishlist
Owner: Charles Fry <[EMAIL PROTECTED]>


* Package name: courieruserinfo
  Version : 1.1.1
  Upstream Author : Andrew St. Jean <[EMAIL PROTECTED]>
* URL : http://www.arda.homeunix.net/store/
* License : GPL
  Description : Retrieve courier user account information

 Courieruserinfo works with the Courier mail server user authentication
 mechanism to allow user account information to be retrieved. The specific
 types of information which can be retrieved are: uid, home directory, name,
 address, mail directory, quota, and options.

-- System Information:
Debian Release: 3.1
  APT prefers testing
  APT policy: (90, 'testing'), (80, 'unstable')
Architecture: i386 (i686)
Kernel: Linux 2.6.8-2-386
Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1)


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

Bug#378569: ITP: courierpasswd -- Authenticate courier passwords with checkpassword interface

[Charles Fry]

Package: wnpp
Severity: wishlist
Owner: Charles Fry <[EMAIL PROTECTED]>


* Package name: courierpasswd
  Version : 1.1.1
  Upstream Author : Andrew St. Jean <[EMAIL PROTECTED]>
* URL : http://www.arda.homeunix.net/store/
* License : GPL
  Description : Authenticate courier passwords with checkpassword interface

 Courierpasswd is a user authentication and password changing utility that
 works with the Courier mail server user authentication mechanism. It's
 interface follows that of checkpassword. It can be used, for example, to
 authenticate users who are sending email through a non-courier MTA.

-- System Information:
Debian Release: 3.1
  APT prefers testing
  APT policy: (90, 'testing'), (80, 'unstable')
Architecture: i386 (i686)
Kernel: Linux 2.6.8-2-386
Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1)


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

Disturbing uploads (Re: release update: Etch 4.0, Blockers and Goals, Arch status, kernel 2.4, etc)

[Luk Claes]

Marc Brockschmidt wrote:

> Please note that as of now, RC bugs and problematic transitions are our
> main concern.  There has been progress, but we still need to lower the
> number of release critical bugs further.  There will be a couple of Bug
> Squashing Parties soon, so please consider to join one or more of them. [1]
> 
> We want to ask you to not do disturbing updates of your packages in
> unstable without contacting the release team before.  If you need a staging
> area or simply want to use Debian infrastructure to show newer packages,
> you can always upload to experimental, which is nowadays mostly autobuilt. [2]

Probably everyone know one should avoid problematic transitions and
disturbing updates of packages, though what looks like a simple change
in your package might be a disturbing update and might cause a
problematic transition...

A simple example would be changing the name of a library package which
has a couple of reverse dependencies. This doesn't look that disturbing
at all... but has the potential to cause major trouble for testing
transition...

Another example would be uploading a package which links some
transitions together...

The first example can cause trouble if the old package is not available
anymore (as virtual package or oldlibs for instance) as all packages
depending on the library package become instantly uninstallable, you
might want to look at [1] for some hints to avoid trouble with this kind
of upload. These uninstallables might cause other uninstallables,
failures to build and a harder testing migration as all these packages
need to be installable again before they can all together transition to
testing...

The second example looks innocent from a package maintainer's point of
view as it might only involve small fixes in packaging or documentation
or whatever. Though it can make life of the Release Team quite hard.

Without the intention to point fingers, lets look at a real life
example, just to show you how things work:

Looking at [2] you see the perl transition which involves 60 packages
(recursively). If you click on perl you see the list of 60 packages.
Looking at these packages you can find out that there are 4 of them
which link other transitions with the perl transition: obexftp,
subversion and rapidsvn. obexftp links the bluez-libs transition with
the perl transition, subversion links the neon transition with the perl
transition and rapidsvn and pdl link the wxwidgets2.6 transition with
the perl transition.

The perl transition is due to the way perl dependencies are handled for
the moment: it makes sure the package will be installable as it depends
on the most recent perl the package was built with.

The bluez-libs transition is actually a transition like the pattern in
the first example. This transition involves 14 source packages (13
extra). kdepim links in the gnokii transition which luckily doesn't
involve extra packages.

The neon transition involves 20 source packages (8 extra), though these
8 don't link other transitions with the neon one.

The wxwidgets2.6 transition involves 12 packages (10 extra), though
these 10 also don't link other transitions with the wxwidgets2.6 one.

So all these packages should enter testing together unless they will
still be installable in testing and the version in unstable is not ready
to enter testing yet (not old enough, RC bug, not built on all release
arches...)

To conclude, please try to avoid linking transitions together and try to
avoid making packages instantly uninstallable if possible.

Cheers

Luk

[1] http://wiki.debian.org/TransitionBestPractices
[2] http://bjorn.haxx.se/debian/stalls.html

-- 
Luk Claes - http://people.debian.org/~luk - GPG key 1024D/9B7C328D
Fingerprint:   D5AF 25FB 316B 53BB 08E7   F999 E544 DE07 9B7C 328D



signature.asc
Description: OpenPGP digital signature

Re: greylisting on debian.org?

[Magnus Holmgren]

On Sunday 16 July 2006 04:35, Thomas Bushnell BSG took the opportunity to 
write:
> Stephen Gran <[EMAIL PROTECTED]> writes:
> > I suggest that when we find a domain that sends mail from 120 /27's
> > (roughly a /20), we worry about it then.
>
> An excellent strategy.  

I think so. How many systems (aside from the "big ones" like MSN, Gmail, ..., 
which are generally known) do you estimate would be affected? At most sites 
outgoing messages stay with the same host until delivered, except after the 
initial delivery attempt a temporarily failed message may be passed to 
a "secondary" MTA.

> Do you have some mechanism in place to detect 
> such a case when or if it happens?

Deal with it when people complain. Also, this kind of information can be 
shared so that not every mail admin has to find it out himself by users 
complaining.

-- 
Magnus Holmgren[EMAIL PROTECTED]
   (No Cc of list mail needed, thanks)


pgpYujtBdEr7I.pgp
Description: PGP signature

Re: release update: Etch 4.0, Blockers and Goals, Arch status, kernel 2.4, etc

[Steinar H. Gunderson]

On Mon, Jul 17, 2006 at 01:18:41PM +, Marc Brockschmidt wrote:
> There was a new request for another approved release goal, that is NFS
> v4 support.  We approved that goal.

AFAICS, that goal has been completed for a while. What's needed in etch is:

 - nfs-utils 1.0.7 or newer (check, 1.0.9 is in)
 - NFSv4 capable mount (check, the patch was approved a while ago)
 - Fairly recent 2.6 kernel (check, I can't imagine etch releasing without at
   least 2.6.16)
 - Support from initscripts to start rpc.idmapd and friends at boot if needed
   by fstab (check, was fixed by NMU)

We currently run NFSv4 in production at our site (vanilla sid clients, sarge
servers with backported nfs-utils and kernels), and it works well for us.

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


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

Re: greylisting on debian.org?

[Stephen Gran]

This one time, at band camp, Magnus Holmgren said:
> On Sunday 16 July 2006 04:35, Thomas Bushnell BSG took the opportunity
> to write:
> > Stephen Gran <[EMAIL PROTECTED]> writes:
> > > I suggest that when we find a domain that sends mail from 120
> > > /27's (roughly a /20), we worry about it then.
> >
> > An excellent strategy.  
> 
> I think so. How many systems (aside from the "big ones" like MSN,
> Gmail, ..., which are generally known) do you estimate would be
> affected? At most sites outgoing messages stay with the same host
> until delivered, except after the initial delivery attempt a
> temporarily failed message may be passed to a "secondary" MTA.

It's not uncommon for big sites to have pools of high throughput
machines that don't have qrunners, and larger pools of machines that do.
The first group gets a message, and tries to deliver immediately, and
any temporary failure gets the messages shunted to the secondary pool.
Once in the secondary pool, it can be bounced from machine to machine
to load balance queue size and so on.

That being said, the original query about this was a strawman argument
designed specifically to find a problem, and I would say fairly
confidently we don't need to worry about this.  I have analyzed the logs
on mail servers I have access to, and I cannot find any site which passes
a message between more than a half dozen or at most a dozen IP addresses
before delivery.  This is two or three orders of magnitude less than
the kind of thing Thomas and others are concerned about.  By the time
sites big enough to use pools that big exist (which I actually doubt -
scalability might just be too hard to manage to be worth it), greylisting
will be another dead tool in the arms race with spammers.

So far, all the arguments against the idea have just been assertions and
strawmen.  Unless someone can present a serious argument, can we
consider this thread done?

Take care,
-- 
 -
|   ,''`.Stephen Gran |
|  : :' :[EMAIL PROTECTED] |
|  `. `'Debian user, admin, and developer |
|`- http://www.debian.org |
 -


signature.asc
Description: Digital signature

Bug#378587: ITP: qrfcview -- viewer for IETF RFCs

[Frederic Daniel Luc LEHOBEY]

Package: wnpp
Severity: wishlist
Owner: Frederic Daniel Luc LEHOBEY <[EMAIL PROTECTED]>

* Package name: qrfcview
  Version : 0.62
  Upstream Author : Romain ROLLET <[EMAIL PROTECTED]>
* URL : http://qrfcview.berlios.de/
* License : GPL
  Programming Lang: C++
  Description : viewer for IETF RFCs

 qRFCView is a viewer for IETF RFC featuring:
 .
  - automatic table of content, with direct opening of section;
  - handling of RFC internal cross-references;
  - automatic downloading of a referenced RFC from the IETF web site
on a simple click;
  - caching of RFC in a local directory;
  - tab-browsing of RFC;
  - searching.
 .
  Homepage: http://qrfcview.berlios.de/


-- 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.8-3-k7
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)


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

intent to hijack python-paramiko

[martin f krafft]

1.6.1 is now upstream, and #344734 is over half a year old. Unless
we hear from the maintainer (Jeremy Bouse, on CC to be sure) by the
end of this week, we will take over the package as it's blocking bzr
0.9, which is to be released RSN. Wouter van Heyst would be the new
maintainer and I'd sponsor.

We'll also upload 1.6.1-0.1 to experimental during the week to make
things easier for us.

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


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

Re: intent to hijack python-paramiko

[Martin Michlmayr]

* martin f krafft <[EMAIL PROTECTED]> [2006-07-17 19:35]:
> 1.6.1 is now upstream, and #344734 is over half a year old. Unless
> we hear from the maintainer (Jeremy Bouse, on CC to be sure) by the
> end of this week, we will take over the package as it's blocking bzr

He was moving cross-country in May, so I suggest you NMU for now.
-- 
Martin Michlmayr
http://www.cyrius.com/


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

Re: greylisting on debian.org?

[Adrian von Bidder]

[sending systems that don't deal with greylisting]

On Monday 17 July 2006 17:36, Magnus Holmgren wrote:
[...]
> Also, this kind of information can be
> shared so that not every mail admin has to find it out himself by users
> complaining.

Some data points:
 * the default greylist shipped by greylist is growing only quite slow, so 
apparently the big players are in there by now.
 * big pools are only the smallest part of that whitelist, so this 
discussion is a bit silly.  The really problematic sites are not really rfc 
compliant: sites that don't retry at all, or that retry with different 
sender addresses (which from the pov of greylisting is the same, 
obviously.)

So the question is, imho, not if we should potentially lock out users of big 
mail pools - those are in the default whitelists anyway by now.  The 
question is: can we temporarily (until they can be whitelisted) lock out 
users of "standards?-who-needs-standards?" systems that don't implement 
sensible queueing.  Many of these sites are small - but there are also a 
few bigger names: Yahoo groups, Amazon, Roche, Motorola. (According to 
postgrey's default whitelist.  Some of these are from 2004 or earlier, and 
AFAIK nobody tries to verify if these systems are still stupid in that 
way.)

cheers
-- vbi

-- 
Wie man sein Kind nicht nennen sollte:
  Hanno Ferr


pgpkWEMiGmTS2.pgp
Description: PGP signature

NFSv4

[Adrian von Bidder]

On Monday 17 July 2006 17:00, Steinar H. Gunderson wrote:
> On Mon, Jul 17, 2006 at 01:18:41PM +, Marc Brockschmidt wrote:
> > There was a new request for another approved release goal, that is NFS
> > v4 support.  We approved that goal.
>
> AFAICS, that goal has been completed for a while.

Small question that could help improving performance here :-)

Does the current NFSv4 implementation already allow client-side on-disk 
caching?  IIRC the standard does specify it, but a quick look at 
linux-nfs.org confuses me - some pages speak about delegations, but OTOH 
the end user pages like 
http://wiki.linux-nfs.org/index.php/NFSv4_Introduction don't mention 
anything.



-- 
Frink!


pgp8GdbKYCFUA.pgp
Description: PGP signature

Re: intent to hijack python-paramiko

[martin f krafft]

also sprach Martin Michlmayr <[EMAIL PROTECTED]> [2006.07.17.1940 +0200]:
> > 1.6.1 is now upstream, and #344734 is over half a year old. Unless
> > we hear from the maintainer (Jeremy Bouse, on CC to be sure) by the
> > end of this week, we will take over the package as it's blocking bzr
> 
> He was moving cross-country in May, so I suggest you NMU for now.

Ok. So upload a 1.6.1-0.1 to unstable?

-- 
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
 
beware of bugs in the above code;
i have only proved it correct, not tried it.
-- donald e. knuth


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

Re: Getting the buildds to notice new architectures in a package

[Joe Smith]

"Wouter Verhelst" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]

On Sat, Jul 15, 2006 at 10:55:32PM +0200, Ludovic Brenta wrote:

Where should I ask for help?  Neither buildd.debian.org nor
www.debian.org/devel/buildd, mention where the buildd admins can be
reached; and lists.debian.org does not have a "buildd@" list.


<[EMAIL PROTECTED]>. I just committed a change to the
wanna-build-states page to that effect.


I will upload ~20 source packages in the next few weeks, adding
support for more architectures to each package.  So I'm really looking
for a general solution and not one that only applies to asis.


There is no such general solution. See



That says:
However, wanna-build does not look at the control file of a package when 
creating its database;

only at the packages' name and section, its urgency, and its priority.


Shouldn't wanna-build use the control file? It would then mean that the 
lists of packages-arch-specific
would not be needed, except in the case of a single version override in the 
event that a package's control
file accidentally listed an architecture on which it is not supported, or 
failed to list an architecture on
which it is supported. 




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

Re: intent to hijack python-paramiko

[Wouter van Heyst]

On Mon, Jul 17, 2006 at 07:40:37PM +0200, Martin Michlmayr wrote:
> * martin f krafft <[EMAIL PROTECTED]> [2006-07-17 19:35]:
> > 1.6.1 is now upstream, and #344734 is over half a year old. Unless
> > we hear from the maintainer (Jeremy Bouse, on CC to be sure) by the
> > end of this week, we will take over the package as it's blocking bzr
> 
> He was moving cross-country in May, so I suggest you NMU for now.

Would NMUing a new upstream be ok in this instance then?

Wouter van Heyst


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

Re: intent to hijack python-paramiko

[Martin Michlmayr]

* Wouter van Heyst <[EMAIL PROTECTED]> [2006-07-17 20:35]:
> > He was moving cross-country in May, so I suggest you NMU for now.
> 
> Would NMUing a new upstream be ok in this instance then?

I think so, yes.
-- 
Martin Michlmayr
http://www.cyrius.com/


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

Processed: Only in stable

[Debian Bug Tracking System]

Processing commands for [EMAIL PROTECTED]:

> retitle 359565 [Stable-only] ruby-manual: please finish /usr/doc transition
Bug#359565: ruby-manual: please finish /usr/doc transition
Changed Bug title.

> unblock 322762 by 359565
Bug#322762: /usr/doc still exists (transition tracking bug)
Was blocked by: 189856 190020 203278 254800 254913 254924 255590 302504 319726 
320084 320103 321926 322749 322769 322772 322776 322778 322779 322781 322782 
322783 322784 322785 322786 322787 322788 322789 322790 322791 322792 322793 
322794 322795 322797 322798 322799 322800 322801 322803 322804 322805 322806 
322807 322808 322809 322810 322811 322812 322813 322814 322815 322816 322817 
322818 322819 322820 322828 322829 322830 322831 322832 322833 322834 322835 
322837 322838 322839 352893 352894 353569 355341 359358 359359 359361 359362 
359363 359364 359365 359366 359367 359368 359369 359370 359371 359372 359374 
359375 359376 359377 359378 359379 359380 359381 359382 359383 359384 359385 
359386 359387 359388 359389 359390 359391 359392 359393 359394 359395 359396 
359399 359400 359401 359403 359405 359406 359407 359408 359409 359410 359411 
359412 359413 359414 359417 359418 359419 359420 359421 359422 359423 359424 
359425 359426 359427 359428 359429 359430 359431 359432 359433 359434 359435 
359436 359437 359439 359440 359441 359442 359443 359444 359445 359446 359447 
359448 359449 359450 359451 359452 359453 359454 359455 359456 359457 359458 
359459 359460 359461 359462 359463 359464 359465 359466 359467 359468 359469 
359470 359471 359472 359473 359474 359475 359476 359477 359478 359479 359480 
359481 359482 359483 359484 359485 359486 359487 359488 359489 359490 359491 
359492 359493 359494 359495 359496 359497 359498 359499 359500 359501 359502 
359503 359504 359505 359506 359507 359508 359509 359510 359511 359512 359513 
359514 359515 359516 359517 359518 359519 359520 359521 359522 359523 359524 
359526 359527 359528 359529 359530 359531 359532 359533 359534 359535 359536 
359537 359538 359539 359540 359541 359542 359543 359544 359545 359546 359547 
359548 359549 359550 359551 359552 359553 359554 359555 359556 359557 359558 
359559 359560 359561 359562 359563 359564 359565 359566 359567 359568 359569 
359570 359571 359572 359573 359574 359575 359576 359577 359578 359579 359580 
359581 359582 359583 359584 359585 359586 359587 359588 359589 359590 359591 
359592 359593 359594 359595 359596 359597 359598 359599 359600 359601 359602 
359603 359604 359605 359606 359607 359608 359609 359610 359611 359612
Blocking bugs of 322762 removed: 359565

> thanks
Stopping processing here.

Please contact me if you need assistance.

Debian bug tracking system administrator
(administrator, Debian Bugs database)


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

Re: NFSv4

[Steinar H. Gunderson]

On Mon, Jul 17, 2006 at 08:03:12PM +0200, Adrian von Bidder wrote:
> Does the current NFSv4 implementation already allow client-side on-disk 
> caching?  IIRC the standard does specify it, but a quick look at 
> linux-nfs.org confuses me - some pages speak about delegations, but OTOH 
> the end user pages like 
> http://wiki.linux-nfs.org/index.php/NFSv4_Introduction don't mention 
> anything.

Yes, the Linux client and server both support delegations. There are still
bugs left, but they're getting better for each kernel version. (I don't know
how one would turn it off, though.)

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


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

Re: greylisting on debian.org?

[Lionel Elie Mamane]

On Sun, Jul 16, 2006 at 08:36:31AM +0200, Christian Perrier wrote:
> Quoting Wolfgang Lonien ([EMAIL PROTECTED]):

>> Do we use greylisting on the @debian.org domain and especially on
>> @lists.debian.org?

> So, up to now, we've found Thomas Bushnell who seems really hardly
> voting against greylisting on Debian hosts, (...).

> So far and unless I forget someone, I haven't seen much other people
> being strongly opposed to greylisting on Debian hosts,

Here is one: I am strongly opposed to greylisting (on mail sent to me
or that I send), for the reason that it delays legitimate mail.

Best Regards,

-- 
Lionel


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

Re: Bits from the Package Tracking System

[Gustavo Franco]

On 7/17/06, Raphael Hertzog <[EMAIL PROTECTED]> wrote:

[...]
New derivatives keyword
---
[...]
The Ubuntu distribution will be the first to make use of this new feature.
Each time that a new package is uploaded to Ubuntu, the PTS will receive
the diff between the new version and the previous one. This way we'll
receive regularly small patches instead of having only a big monolithic
patch on http://patches.ubuntu.com/ (those will continue to be updated
anyway). Those mails will look like this:
https://lists.ubuntu.com/archives/ubuntu-patches/2006-July/thread.html
[...]


Please tell me when they start doing this, so i'll stop scottwatcher.

thanks,
-- stratus


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

Re: greylisting on debian.org?

[Thomas Bushnell BSG]

Christian Perrier <[EMAIL PROTECTED]> writes:

> So, up to now, we've found Thomas Bushnell who seems really hardly
> voting against greylisting on Debian hosts, with arguments about it
> breaking established standards. I personnally find these arguments
> very nitpicking and mostly aimed at finding a justification for an
> opinion that will definitely not change.

I'm not a nitpicker for its own sake; I'm a nitpicker for the
principle "be liberal in what you accept and conservative in what you
send."  That calls for being nitpicky on one side and not the other.

Still, if you think it's just nitpicking, then why not ask the IETF to
amend the standard to clearly permit this practice?

And finally, if we don't care about standards conformance, I have said
that a good second-best is to document exactly what our requirements
are, rather than burying them in apparent secrecy.

This is not about stonewalling.  So how about the last of these: clear
and accurate documentation?

Thomas


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

Re: greylisting on debian.org?

[Thomas Bushnell BSG]

Magnus Holmgren <[EMAIL PROTECTED]> writes:

>> Do you have some mechanism in place to detect 
>> such a case when or if it happens?
>
> Deal with it when people complain. Also, this kind of information can be 
> shared so that not every mail admin has to find it out himself by users 
> complaining.

Are you willing to promise that if someone gives a genuine complaint
about how this is blocking their legitimat email, you will amend your
practice to deal, rather than to insist that they should change
theirs?

Thomas


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

what's the python status?

[Thomas Bushnell BSG]

So presumably the python transition is now ready for changing the
version on python defaults, right?  What remains to be done?

I would ask directly, but they have not yet responded to any question
I have asked.

Thomas


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

Re: Getting the buildds to notice new architectures in a package

[Wouter Verhelst]

On Mon, Jul 17, 2006 at 02:40:28PM -0400, Joe Smith wrote:
> "Wouter Verhelst" <[EMAIL PROTECTED]> wrote in message 
> >There is no such general solution. See
> >
> 
> That says:
> >However, wanna-build does not look at the control file of a package
> >when creating its database; only at the packages' name and section,
> >its urgency, and its priority.
> 
> Shouldn't wanna-build use the control file?

Perhaps. The issue is that wanna-build needs to know whether a package
has already been built for its architecture; one can only find that out
by looking at the Packages file, and comparing that with the Sources
file.

Since the Packages and Sources files contain all the information
wanna-build needs (except for the architectures for which a build should
be attempted), and since fetching the control files is a _lot_ more work
than to write a parser for Packages and Sources files which can just be
piped into wanna-build, it isn't done.

Also, such a thing would probably require quite some I/O, so I'm not
entirely sure it's worth it. But if you could write some patch which
does not ever break and which allows to read the control file, I'm sure
it'll be welcome.

(I'm not sure why it still listed "upload urgency" as a criterion there
-- that's a bug in the documentation that I introduced, but it's never
been true. I've just committed a fix)

> It would then mean that the lists of packages-arch-specific would not
> be needed, except in the case of a single version override in the
> event that a package's control file accidentally listed an
> architecture on which it is not supported, or failed to list an
> architecture on which it is supported. 

The latter wouldn't work anyway -- if it isn't supported,
dpkg-buildpackage refuses to build the package.

-- 
Fun will now commence
  -- Seven Of Nine, "Ashes to Ashes", stardate 53679.4


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

Re: greylisting on debian.org?

[Pierre Habouzit]

Le lun 17 juillet 2006 19:53, Adrian von Bidder a écrit :


> So the question is, imho, not if we should potentially lock out users
> of big mail pools - those are in the default whitelists anyway by
> now.  The question is: can we temporarily (until they can be
> whitelisted) lock out users of "standards?-who-needs-standards?"
> systems that don't implement sensible queueing.  Many of these sites
> are small - but there are also a few bigger names: Yahoo groups,
> Amazon, Roche, Motorola. (According to postgrey's default whitelist. 
> Some of these are from 2004 or earlier, and AFAIK nobody tries to
> verify if these systems are still stupid in that way.)

OTOH those systems are not listed on RBL's (or it does not last) and you 
won't greylist them.
-- 
·O·  Pierre Habouzit
··O[EMAIL PROTECTED]
OOOhttp://www.madism.org


pgpQYwSHKTXs9.pgp
Description: PGP signature

Re: greylisting on debian.org?

[Stephen Gran]

This one time, at band camp, Thomas Bushnell BSG said:
> And finally, if we don't care about standards conformance, I have said
> that a good second-best is to document exactly what our requirements
> are, rather than burying them in apparent secrecy.

What standards, exactly?  Can you be specific?  I have seen you assert
this several times, but I see nothing in the RFCs preventing a site from
saying it has a temporary local problem when it doesn't.  You've been
asked this before in response to your assertion, and haven't answered.
-- 
 -
|   ,''`.Stephen Gran |
|  : :' :[EMAIL PROTECTED] |
|  `. `'Debian user, admin, and developer |
|`- http://www.debian.org |
 -


signature.asc
Description: Digital signature

Bug#378626: ITP: pulseaudio -- networked sound server

[Loïc Minier]

Package: wnpp
Severity: wishlist
Owner: Loic Minier <[EMAIL PROTECTED]>

Hi,

* Package name: pulseaudio
  Version : 0.9.2
  Upstream Author : Lennart Poettering, Pierre Ossman
* URL : http://www.pulseaudio.org/
* License : LGPL, some parts have GPL deps
  Programming Lang: C, Python
  Description : networked sound server

 PulseAudio, previously known as Polypaudio, is a networked sound
 server.
 .
 A sound server is basically a proxy for your sound applications.  It
 allows to do advanced operations on sound data as it passes between
 application and hardware.  Things like transferring the audio to a
 different machine, changing the sample format or channel count and
 mixing several sounds into one are easily achieved using a sound
 server.


 I do not intend to re-use the Ubuntu PolypAudio packages.

 There's room for co-maintenance, I intend to use an Alioth project.

   Bye,
-- 
Loïc Minier <[EMAIL PROTECTED]>

Re: greylisting on debian.org?

[Pierre Habouzit]

Le lun 17 juillet 2006 22:29, Lionel Elie Mamane a écrit :
> Here is one: I am strongly opposed to greylisting (on mail sent to me
> or that I send), for the reason that it delays legitimate mail.

which shows that you didn't read the discussion that was about enabling 
greylisting on *certain* *specificaly* *suspicious* hosts. a suspicious 
host is:
 * either listed on some RBL's (rbl listing "dynamic" blocks are a good
   start usually)
 * either having no reverse DNS set
 * either having curious EHLO lines (that one may catch too much good
   mail sadly, so it's to handle with care).
 * ...

I apply greylisting on the two first criteriums on a quite used mail 
server (around 300.k mails per week, which is not very big, but should 
be representative enough).

there is less than 50 mails a week over those that *may* be legitimate 
mails that are actually slowed down.

so *please* do me a favour, read the thread you are answering to, 
because you really really answer miles away from the debate.

and if you never actually realized, there *IS* such a slowdown on debian 
mail lists, it's called crossassassin, it kills master on a regular 
basis, and is *REALLY* less effective than greylisting.

when spam makes our MX load go to highs I never suspected a machine 
could resist, I think maybe it's time to try a more robust solution.

Pierre, that is pissed that his @debian.org address barely more usable 
than a hotmail one (and I do not know any worse mail service on the 
entire web).
-- 
·O·  Pierre Habouzit
··O[EMAIL PROTECTED]
OOOhttp://www.madism.org


pgpvRDQPt81wu.pgp
Description: PGP signature

Re: Bits from the Package Tracking System

[Stefano Zacchiroli]

On Mon, Jul 17, 2006 at 10:39:18PM +0200, Raphael Hertzog wrote:
> New derivatives keyword
> ---
> Each time that a new package is uploaded to Ubuntu, the PTS will receive
> the diff between the new version and the previous one. This way we'll

Is an archive of those mails available somewhere? This way the "small
patches" will be available even for packages of people not subscribed to
the PTS. Or for people who subscribe after some version has been
uploaded to ubuntu.

A dumb way to implement that is of course set up a mail account
subscribed to all packages with the derivative keyword. I can set up
such an account, but I guess there exists an easier solution for setting
up the archive on the PTS side. Could you comment on that?

Thanks for all this work!

Cheers.

-- 
Stefano Zacchiroli -*- Computer Science PhD student @ Uny Bologna, Italy
[EMAIL PROTECTED],debian.org,bononia.it} -%- http://www.bononia.it/zack/
If there's any real truth it's that the entire multidimensional infinity
of the Universe is almost certainly being run by a bunch of maniacs. -!-


signature.asc
Description: Digital signature

Re: greylisting on debian.org?

[Adam Borowski]

On Mon, Jul 17, 2006 at 10:42:22PM +0100, Stephen Gran wrote:
> This one time, at band camp, Thomas Bushnell BSG said:
> > And finally, if we don't care about standards conformance, I have said
> > that a good second-best is to document exactly what our requirements
> > are, rather than burying them in apparent secrecy.
> 
> What standards, exactly?  Can you be specific?  I have seen you assert
> this several times, but I see nothing in the RFCs preventing a site from
> saying it has a temporary local problem when it doesn't.

Even worse, there's nothing preventing a site from saying it has a
temporary local problem when it _does_.  Thus, if your mail server
can't handle retrying, it will drop mail every time something is not
in perfect working order.  And hardware or network failures are
something to be expected.

Any legitimate server must support retrying.  For any reason.

-- 
1KB // Microsoft corollary to Hanlon's razor:
//  Never attribute to stupidity what can be
//  adequately explained by malice.


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

Re: Bits from the Package Tracking System

[Gustavo Franco]

On 7/17/06, Stefano Zacchiroli <[EMAIL PROTECTED]> wrote:

On Mon, Jul 17, 2006 at 10:39:18PM +0200, Raphael Hertzog wrote:
> New derivatives keyword
> ---
> Each time that a new package is uploaded to Ubuntu, the PTS will receive
> the diff between the new version and the previous one. This way we'll

Is an archive of those mails available somewhere? This way the "small
patches" will be available even for packages of people not subscribed to
the PTS. Or for people who subscribe after some version has been
uploaded to ubuntu.


https://lists.ubuntu.com/archives/ubuntu-patches/


A dumb way to implement that is of course set up a mail account
subscribed to all packages with the derivative keyword. I can set up
such an account, but I guess there exists an easier solution for setting
up the archive on the PTS side. Could you comment on that?



Maybe we need to mirror the ubuntu-patches mailing list archive. utnubu's
work, i guess. :-)

regards,
-- stratus


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

Re: greylisting on debian.org?

[Magnus Holmgren]

On Monday 17 July 2006 23:41, Pierre Habouzit took the opportunity to write:
> Le lun 17 juillet 2006 19:53, Adrian von Bidder a écrit :
> > So the question is, imho, not if we should potentially lock out users
> > of big mail pools - those are in the default whitelists anyway by
> > now.  The question is: can we temporarily (until they can be
> > whitelisted) lock out users of "standards?-who-needs-standards?"
> > systems that don't implement sensible queueing.  Many of these sites
> > are small - but there are also a few bigger names: Yahoo groups,
> > Amazon, Roche, Motorola. (According to postgrey's default whitelist.
> > Some of these are from 2004 or earlier, and AFAIK nobody tries to
> > verify if these systems are still stupid in that way.)
>
> OTOH those systems are not listed on RBL's (or it does not last) and you
> won't greylist them.

Which RBL's do you have in mind? I mean, some RBL's, like XBL/SBL, are 
high-quality enough that you can outright reject. Others, like SpamCop, are 
likely to include some of the bigger names from time to time. DUL lists might 
be good candidates.

-- 
Magnus Holmgren[EMAIL PROTECTED]
   (No Cc of list mail needed, thanks)


pgpShTNmCba9F.pgp
Description: PGP signature

Re: Bits from the Package Tracking System

[Stefano Zacchiroli]

On Mon, Jul 17, 2006 at 06:59:41PM -0300, Gustavo Franco wrote:
> https://lists.ubuntu.com/archives/ubuntu-patches/

That's indeed great to address my concern but ...

> >A dumb way to implement that is of course set up a mail account
> >subscribed to all packages with the derivative keyword. I can set up
> >such an account, but I guess there exists an easier solution for setting
> >up the archive on the PTS side. Could you comment on that?
> Maybe we need to mirror the ubuntu-patches mailing list archive. utnubu's
> work, i guess. :-)

... does not extend to other possible derivatives. I agree that
mirroring that list could be a work for utnubu, but a more general
solution would be to provide an archive of pts notifications. Don't know
if at large (i.e. for all keywords) or only for derivatives (a reason
for this could be that for all other keywords we actually can reproduce
the event who triggered the notification; I'm actually not sure if this
is the case or not).

Cheers.

-- 
Stefano Zacchiroli -*- Computer Science PhD student @ Uny Bologna, Italy
[EMAIL PROTECTED],debian.org,bononia.it} -%- http://www.bononia.it/zack/
If there's any real truth it's that the entire multidimensional infinity
of the Universe is almost certainly being run by a bunch of maniacs. -!-


signature.asc
Description: Digital signature

Re: greylisting on debian.org?

[Magnus Holmgren]

On Monday 17 July 2006 23:27, Thomas Bushnell BSG took the opportunity to 
write:
> Magnus Holmgren <[EMAIL PROTECTED]> writes:
> > Deal with it when people complain. Also, this kind of information can be
> > shared so that not every mail admin has to find it out himself by users
> > complaining.
>
> Are you willing to promise that if someone gives a genuine complaint
> about how this is blocking their legitimat email, you will amend your
> practice to deal, rather than to insist that they should change
> theirs?

Parse error. If someone complains because their mail servers are too spread 
out, I'd whitelist them. If someone complains because their own software is 
broken, well, that depends. I would explain to them nicely why they should 
fix it, but I wouldn't argue unless I have a good reason to do so. Nothing 
needs to be amended.

-- 
Magnus Holmgren[EMAIL PROTECTED]
   (No Cc of list mail needed, thanks)


pgpt7qL58rXV8.pgp
Description: PGP signature

Re: Bits from the Package Tracking System

[Scott James Remnant]

On 2006-07-17 20:48, Gustavo Franco wrote:

> On 7/17/06, Raphael Hertzog <[EMAIL PROTECTED]> wrote:
> > [...]
> > New derivatives keyword
> > ---
> > [...]
> > The Ubuntu distribution will be the first to make use of this new feature.
> > Each time that a new package is uploaded to Ubuntu, the PTS will receive
> > the diff between the new version and the previous one. This way we'll
> > receive regularly small patches instead of having only a big monolithic
> > patch on http://patches.ubuntu.com/ (those will continue to be updated
> > anyway). Those mails will look like this:
> > https://lists.ubuntu.com/archives/ubuntu-patches/2006-July/thread.html
> > [...]
> 
> Please tell me when they start doing this, so i'll stop scottwatcher.
> 
We were just waiting on Raphael announcing the changes to the PTS before
we started sending, so as not to surprise anyone -- they are being sent
now (assuming everything works )

Scott
-- 
Scott James Remnant
[EMAIL PROTECTED]


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

Re: greylisting on debian.org?

[Josselin Mouette]

Le lundi 17 juillet 2006 à 22:29 +0200, Lionel Elie Mamane a écrit :
> On Sun, Jul 16, 2006 at 08:36:31AM +0200, Christian Perrier wrote:
> > Quoting Wolfgang Lonien ([EMAIL PROTECTED]):
> 
> >> Do we use greylisting on the @debian.org domain and especially on
> >> @lists.debian.org?
> 
> > So, up to now, we've found Thomas Bushnell who seems really hardly
> > voting against greylisting on Debian hosts, (...).
> 
> > So far and unless I forget someone, I haven't seen much other people
> > being strongly opposed to greylisting on Debian hosts,
> 
> Here is one: I am strongly opposed to greylisting (on mail sent to me
> or that I send), for the reason that it delays legitimate mail.

I have refused greylisting for a long time for that exact reason.
However the setup Pierre Habouzit describes does not delay most of
legitimate mail. Frankly, the remaining delays are sporadic and one can
live with them.

I'm applying greylisting if one of these conditions is met:
  * the incoming IP is listed in a DUL;
  * Exim sender/callout fails with a fatal error.
This setup has considerably reduced both the load and the amount of spam
on the server. However I still have to deal with @debian.org spam with a
less and less efficient (and more and more cpu consuming) bayesian
filter, as it cannot be filtered out this way.
-- 
 .''`.   Josselin Mouette/\./\
: :' :   [EMAIL PROTECTED]
`. `'[EMAIL PROTECTED]
  `-  Debian GNU/Linux -- The power of freedom


signature.asc
Description: Ceci est une partie de message	numériquement signée

Re: greylisting on debian.org?

[Marco d'Itri]

On Jul 17, Thomas Bushnell BSG <[EMAIL PROTECTED]> wrote:

> Still, if you think it's just nitpicking, then why not ask the IETF to
> amend the standard to clearly permit this practice?
Because there is no reason to do this, this is not a standard issue but
plain operations.

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Re: Bits from the Package Tracking System

[Gustavo Franco]

On 7/17/06, Stefano Zacchiroli <[EMAIL PROTECTED]> wrote:

On Mon, Jul 17, 2006 at 06:59:41PM -0300, Gustavo Franco wrote:
> https://lists.ubuntu.com/archives/ubuntu-patches/

That's indeed great to address my concern but ...

> >A dumb way to implement that is of course set up a mail account
> >subscribed to all packages with the derivative keyword. I can set up
> >such an account, but I guess there exists an easier solution for setting
> >up the archive on the PTS side. Could you comment on that?
> Maybe we need to mirror the ubuntu-patches mailing list archive. utnubu's
> work, i guess. :-)

... does not extend to other possible derivatives. I agree that
mirroring that list could be a work for utnubu, but a more general
solution would be to provide an archive of pts notifications. Don't know
if at large (i.e. for all keywords) or only for derivatives (a reason
for this could be that for all other keywords we actually can reproduce
the event who triggered the notification; I'm actually not sure if this
is the case or not).



You've a point, but since there are no other derivative doing the same
(they should), i think the mirror would be enough atm.

regards,
-- stratus


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

Re: Bits from the Package Tracking System

[Gustavo Franco]

On 7/17/06, Scott James Remnant <[EMAIL PROTECTED]> wrote:

On 2006-07-17 20:48, Gustavo Franco wrote:

> On 7/17/06, Raphael Hertzog <[EMAIL PROTECTED]> wrote:
> > [...]
> > New derivatives keyword
> > ---
> > [...]
> > The Ubuntu distribution will be the first to make use of this new feature.
> > Each time that a new package is uploaded to Ubuntu, the PTS will receive
> > the diff between the new version and the previous one. This way we'll
> > receive regularly small patches instead of having only a big monolithic
> > patch on http://patches.ubuntu.com/ (those will continue to be updated
> > anyway). Those mails will look like this:
> > https://lists.ubuntu.com/archives/ubuntu-patches/2006-July/thread.html
> > [...]
>
> Please tell me when they start doing this, so i'll stop scottwatcher.
>
We were just waiting on Raphael announcing the changes to the PTS before
we started sending, so as not to surprise anyone -- they are being sent
now (assuming everything works )



Thanks Scott, i'll stop scottwatcher and update the current page[0]
with details about the new stuff.

[0] =
http://people.debian.org/~stratus/scottwatcher/

regards,
-- stratus


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

Re: greylisting on debian.org?

[Pierre Habouzit]

Le mar 18 juillet 2006 00:08, Magnus Holmgren a écrit :
> On Monday 17 July 2006 23:41, Pierre Habouzit took the opportunity to 
write:
> > Le lun 17 juillet 2006 19:53, Adrian von Bidder a écrit :
> > > So the question is, imho, not if we should potentially lock out
> > > users of big mail pools - those are in the default whitelists
> > > anyway by now.  The question is: can we temporarily (until they
> > > can be whitelisted) lock out users of
> > > "standards?-who-needs-standards?" systems that don't implement
> > > sensible queueing.  Many of these sites are small - but there are
> > > also a few bigger names: Yahoo groups, Amazon, Roche, Motorola.
> > > (According to postgrey's default whitelist. Some of these are
> > > from 2004 or earlier, and AFAIK nobody tries to verify if these
> > > systems are still stupid in that way.)
> >
> > OTOH those systems are not listed on RBL's (or it does not last)
> > and you won't greylist them.
>
> Which RBL's do you have in mind? I mean, some RBL's, like XBL/SBL,
> are high-quality enough that you can outright reject. Others, like
> SpamCop, are likely to include some of the bigger names from time to
> time. DUL lists might be good candidates.

I personnaly use DUL, rfc-ignorant and XBL/SBL.
-- 
·O·  Pierre Habouzit
··O[EMAIL PROTECTED]
OOOhttp://www.madism.org


pgpgIScRRQMZr.pgp
Description: PGP signature

Re: Bits from the Package Tracking System

[Raphael Hertzog]

On Mon, 17 Jul 2006, Stefano Zacchiroli wrote:
> Is an archive of those mails available somewhere? This way the "small
> patches" will be available even for packages of people not subscribed to
> the PTS. Or for people who subscribe after some version has been
> uploaded to ubuntu.

There's only the mailing list archive on the Ubuntu side for now.

I agree that the PTS should have a web archive for all the content that is
generated mainly for it and that is not simply relayed via it (like the
BTS mails).

Nobody has implemented that yet though, and it will also be quite
expensive on disk size... (it shouldn't be a big worry however given the
disk size that recent Debian servers tend to have)

> A dumb way to implement that is of course set up a mail account
> subscribed to all packages with the derivative keyword. I can set up
> such an account, but I guess there exists an easier solution for setting
> up the archive on the PTS side. Could you comment on that?

Please don't go to the "quick & dirty" route. With the scale of the PTS
you would simply create unnecessary load for the mail processing that
master.debian.org really doesn't need.

The PTS scripts receive the mail directly, they can be patched to store a
copy for the web frontend. Someone just needs to do it prperly... (cf my
call for help at the of the announce ;-)).

Cheers,
-- 
Raphaël Hertzog

Premier livre français sur Debian GNU/Linux :
http://www.ouaza.com/livre/admin-debian/


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