Bug#421357: ITP: bzr-gtk -- GTK+ interface to bzr

[Jelmer Vernooij]

Package: wnpp
Severity: wishlist
Owner: Jelmer Vernooij <[EMAIL PROTECTED]>

* Package name: bzr-gtk
  Version : 0.15.2
  Upstream Author : Szilveszter Farkas <[EMAIL PROTECTED]>
Jelmer Vernooij <[EMAIL PROTECTED]> 
et al.
* URL : http://www.bazaar-vcs.org/BzrGtk
* License : GPL
  Programming Lang: Python
  Description : GTK+ interface to bzr

A plugin for Bazaar that aims to provide GTK+ interfaces to most
Bazaar operations.

It provide the following bzr command : gcommit, gdiff, visualise,
gannotate, gbranch, gmissing, gpreferences, gconflicts, gstatus and
commit-notify. 

(packaged will be maintained by the pkg-bazaar-maint team)

-- System Information:
Debian Release: 4.0
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.18-4-k7
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)


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

Bug#421373: ITP: popstation -- A tool to convert PSX iso to EPB

[Gaëtan]

Package: wnpp
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org

License: GNU/GPL
This tool allows you to convert your Sony PSX iso/bin files to Sony PSP
eboot.
The generated EBP file with popstation must be run at least under
3.02OEfirmware (without compression) or under
3.03OE firmware (with compression).
Homepage: http://www.dark-alex.org/

DSC:
http://mentors.debian.net/debian/pool/main/p/popstation/popstation_3.03-1.dsc
--
Gaëtan Petit
Mon weblog - http://www.tenshu.fr/

Ce mail est signé numériquement par FireGPG afin de garantir son
authenticité.

Re: Feature request for GnuPG crypted Debian packages

[Pierre THIERRY]

Scribit Michelle Konzack dies 25/04/2007 hora 20:44:
> > I think you're targetting the wrong layer of the system. If many
> > packages contain so much sensitive data, it would be easier to
> > encrypt a tarball or part of a FS where packages are read.
> The packages are in general on the Server!

Could you be more precise? First ISTR you talked about a CD with
sensitive data. Now there's a package server. The two scenario are
completely different, and call for completely different protection
schemes, I'd say.

> > As far as D-I is concerned, you could probably easily add a udeb to
> > deal with decrypting and unpacking of that senstive part, and leave
> > apt and dpkg untouched.
> You mean, put the crypred tarball into the DEB?

No. I mean you could have an encrypted tarball on the debian installer
CD, and that tarball could be unpacked by a compononent of the
installer. The debian packages in the tarball would then be reachable by
apt and dpkg in a totally normal way (you could either add another
source or use some union FS).

> > On the other hand, if not all the Debian package is sensitive, you
> > better be encrypting data inside it, and have the application or an
> > helper decrypt it when needed, maybe in maintainer scripts.
> I was trying this too, but Sometimes I get conflicts with Packages
> containing the same files.

Then your files are probably at the wrong place, and the packages
probably aren't FHS compliant. Correct them before "enhancing" dpkg to
work around the issue.

Quickly,
Pierre
-- 
[EMAIL PROTECTED]
OpenPGP 0xD9D50D8A


signature.asc
Description: Digital signature

R you happy

[Chicarelli Gary]

Do you mean get banged by your  pennis with handsome woman?  Look www.2211122. 
And add COM after dot at the end.

�Abemus Papam� grid� qualcuno e le campane suonarono a festa.

Lei vorrebbe 100 mani per tappare ogni ferita, poi i soccorsi�Muore in 
ospedale. A 17 anni, Dio.Sospirando mi metto a piangere.
Tradimento. Tradimento. Tradimento.  dentro di me alla ricerca del frutto che, 
ora, siamo in due a mangiare.
 
 
 


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

Re: Bug#421310: ITP: pam-krb5-migrate -- PAM module for migrating to Kerberos

[Jelmer Vernooij]

Hi Steve, Russ,

Op vrijdag 27-04-2007 om 22:25 uur [tijdzone -0700], schreef Steve
Langasek:
> On Fri, Apr 27, 2007 at 10:12:59PM -0700, Russ Allbery wrote:
> > Steve Langasek <[EMAIL PROTECTED]> writes:
> > > On Fri, Apr 27, 2007 at 06:00:34PM -0700, Russ Allbery wrote:
> 
> > >> How does it handle the Kerberos administrative operations?  Is it
> > >> shelling out to kadmin, or did you find a better way to handle that?
> 
> > > It links to libkadm5clnt.  The code was written well before libkadm5 had
> > > a suitable public API, so it hasn't been packaged before now because any
> > > migrations I needed it for are long done. :)
> 
> > libkadm5clnt still doesn't have a public API so far as I know, which is
> > one of the reasons why I was asking.  Because the API is private and no
> > header files are available for it, I'm not sure how rigorous the shared
> > library versioning is between releases for packages that use the internal
> > interface.  MIT generally reserves the right to break use of any symbol
> > that's not exported and documented in the public API.
> 
> Ah, then I don't know.  It's been several years since I spoke with Sam about
> wanting this API to be made public, and I'd pretty much put
> pam_krb5_migrate out of mind until Jelmer brought it up again.  I'd taken
> his word for it that it was buildable now against the public header
> packages.
At the moment, I only build it against Heimdal, which does export these
symbols and provides them in public headers. 

Building against MIT works, but requires the MIT source to be around.
I'll wait for #191616 to be fixed until providing packages against MIT.

Cheers,

Jelmer


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

Re: Bug#421310: ITP: pam-krb5-migrate -- PAM module for migrating to Kerberos

[Russ Allbery]

Jelmer Vernooij <[EMAIL PROTECTED]> writes:

> At the moment, I only build it against Heimdal, which does export these
> symbols and provides them in public headers.

Ah!  Yes, that works.

-- 
Russ Allbery ([EMAIL PROTECTED])   


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

Re: Bug#421107: ITP: torbutton -- iceweasel/icedove extension enabling 1-click toggle of Tor usage

[Greg Folkert]

On Sat, 2007-04-28 at 15:45 +0900, Charles Plessy wrote:
> Le Thu, Apr 26, 2007 at 04:16:29PM +0200, Jérémy Bobbio a écrit :
> > Package: wnpp
> > Severity: wishlist
> > Owner: "Jérémy Bobbio" <[EMAIL PROTECTED]>
> > 
> > Torbutton is a 1-click way for Iceweasel/Icedove users to enable or disable 
> > the
> > browser's use of Tor.
> 
> Hi,
> 
> maybe you can remind what Tor is ?

http://tor.eff.org/

HTH.
-- 
greg, [EMAIL PROTECTED]

Novell's Directory Services is a competitive product to Microsoft's
Active Directory in much the same way that the Saturn V is a competitive
product to those dinky little model rockets that kids light off down at
the playfield. -- Thane Walkup


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

Re: Bug#421107: ITP: torbutton -- iceweasel/icedove extension enabling 1-click toggle of Tor usage

[Ron Johnson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 04/28/07 13:28, Greg Folkert wrote:
> On Sat, 2007-04-28 at 15:45 +0900, Charles Plessy wrote:
>> Le Thu, Apr 26, 2007 at 04:16:29PM +0200, Jérémy Bobbio a écrit :
>>> Package: wnpp
>>> Severity: wishlist
>>> Owner: "Jérémy Bobbio" <[EMAIL PROTECTED]>
>>>
>>> Torbutton is a 1-click way for Iceweasel/Icedove users to enable or disable 
>>> the
>>> browser's use of Tor.
>> Hi,
>>
>> maybe you can remind what Tor is ?
> 
> http://tor.eff.org/

Full Descriptions usually (should) still have such a blurb in them.

- --
Ron Johnson, Jr.
Jefferson LA  USA

Give a man a fish, and he eats for a day.
Hit him with a fish, and he goes away for good!

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

iD8DBQFGM5/fS9HxQb37XmcRAv29AJ4oExzgxhVbIMBbs93gFDmaZfMjAgCg7eMf
l8qVouGxQ1vs6wdbI6Qid/g=
=xhOs
-END PGP SIGNATURE-


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

Re: should an init-script print output, if verbose is set to no in /etc/default/rcS or by /lib/init/vars.sh?

[Marc Haber]

On Wed, 18 Apr 2007 03:17:43 -0700, Steve Langasek <[EMAIL PROTECTED]>
wrote:
>Further, why should individual init scripts that are already going to all
>the effort of using the LSB interfaces be expected to handle VERBOSE
>individually?  Why isn't this part of the log_* implementation?

The LSB init script stuff is a red herring anyway since the Interface
is badly designed and utterly incomplete. Init scripts are therefore
forced to abuse the provided functions if something "special" is
needed.

Greetings
Marc

-- 
-- !! No courtesy copies, please !! -
Marc Haber |   " Questions are the | Mailadresse im Header
Mannheim, Germany  | Beginning of Wisdom " | http://www.zugschlus.de/
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834

pbuilder + local backports question

[Nikita V. Youshchenko]

Hello.

I'm trying to use pbuilder to build some local backports (from post-etch to 
etch).

In most cases, I want all build-deps to be installed from etch.
However, sometimes some particular packages are wanted from other 
repository (where previously build backports are located). This should be 
done only if explicitly requested; by default etch versions still should 
be used

How to do that?

pbuilder-satisfybuilddeps is not smart enough to try packages from 
repository with lower pin-priority, even if build-depends is versioned. It 
just installs default version, without any notice.

"--extrapackages foo/etch-backports" pbuilder arg semi-works, but it is 
triggered after build deps are installed, causing upgrades. Not very good 
IMO.

The only solution I could think is to add a pre-unpack hook that will 
generate /etc/apt/preferences to force needed packages from alternative 
repository. Based on some environment variable, or something alike.

Any other hints/ideas?


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

Re: should an init-script print output, if verbose is set to no in /etc/default/rcS or by /lib/init/vars.sh?

[Warren Turkal]

On Saturday 28 April 2007 15:23, Marc Haber wrote:
> The LSB init script stuff is a red herring anyway since the Interface
> is badly designed and utterly incomplete. Init scripts are therefore
> forced to abuse the provided functions if something "special" is
> needed.

Could you elaborate on this thought? It may be useful to think about for 
extending the LSB semantics and rolling them into the standard.

wt
-- 
Warren Turkal


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

Re: should an init-script print output, if verbose is set to no in /etc/default/rcS or by /lib/init/vars.sh?

[Russ Allbery]

Marc Haber <[EMAIL PROTECTED]> writes:
> Steve Langasek <[EMAIL PROTECTED]> wrote:

>> Further, why should individual init scripts that are already going to
>> all the effort of using the LSB interfaces be expected to handle
>> VERBOSE individually?  Why isn't this part of the log_* implementation?

> The LSB init script stuff is a red herring anyway since the Interface is
> badly designed and utterly incomplete. Init scripts are therefore forced
> to abuse the provided functions if something "special" is needed.

Is there any way that we can fix this?  I *really* like the basic idea and
would be quite happy to never again write an "echo -n" in an init script.
Getting all of the output right to look reasonable even in a pure text
interface is kind of a pain, and I can definitely see why different people
may prefer different output formats for the boot messages.  But the
current provided functions have some significant issues.

To take one of the most obvious, they don't deal with failure at all well.
If you try to start something and it fails with an error message, you end
up with the error message plastered after the starting message without any
blank line (and therefore often going over 80 columns), then a newline and
a space, and then the failed message.

They also don't deal at all well with programs that produce console output
when they start (fairly common when loading kernel modules, for instance).
I need some way to tell the output system that I'm about to do something
that's going to produce output and they should do something reasonable
with the formatting rather than just tack it on to the end of whatever
line happens to be on the screen.

And maybe it's just me, but having a library of convenience functions
that, if used according to directions, end up having you write code like
this seems rather silly:

[ "$VERBOSE" != no ] && log_daemon_msg "Starting $DESC" "$NAME"
do_start_kdc
case "$?" in
  0|1)
if [ "x$RUN_KRB524D" = "xtrue" ] ; then
[ "$VERBOSE" != no ] && log_progress_msg "krb524d"
do_start_krb524d
case "$?" in
  0|1) [ "$VERBOSE" != no ] && log_end_msg 0 ;;
  2)   [ "$VERBOSE" != no ] && log_end_msg 1 ;;
esac
else
[ "$VERBOSE" != no ] && log_end_msg 0
fi
;;
  2)
[ "$VERBOSE" != no ] && log_end_msg 1
;;

Surely the library should be dealing with some of this sort of thing.

I don't have any time at all to work on this personally, but I'm happy to
send this somewhere as a bug report or something if it would be helpful
and I'll gladly cheer on someone else who wants to tackle this!

I've been pushing back on having lintian warn when the LSB functions
aren't used precisely because things like this mean that I'm not at all
convinced they're an improvement.  I think that if these issues were
addressed, they *would* be an improvement, and there are some significant
benefits to be gained from running everything through a central set of
functions for exactly the same reasons that we do the same thing with
package installation prompting and debconf.

-- 
Russ Allbery ([EMAIL PROTECTED])   


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

Re: Mandatory -dbg packages for libraries? (and API docs too)

[Steve Langasek]

On Wed, Apr 25, 2007 at 04:23:38PM +0200, Stefano Zacchiroli wrote:
> On Tue, Apr 24, 2007 at 08:12:46AM -0700, Steve Langasek wrote:
> > > If we are talking about hand-written documentation you're of course
> > > right. However if you're talking about documentation which can be
> > > generated automatically from sources (and not that it was the "ideal"
> > > point of Neil) than you're not.
> > There are ways to generate manpages from --help output of programs.  We
> > still have a lot of programs in Debian with no manpages.

> According to my experience with html2man doesn't work that properly
> every time, but I see your point. But still I don't get the objection:
> is the laziness of people a good reason not to state the "right" path?

Is this "right" path going to describe best practices for providing *good*
API documentation?  Some maintainers will do anything policy (or lintian)
tells them to.  If you say "libraries must include API documentation" in
policy, they'll write API documentation -- even if they don't know how to
write documentation or don't understand the API.  Wrong API docs are surely
worse than not having no docs, aren't they?

> > > It happened to me many times to find library -dev packages with upstream
> > > sources commented with some literate programming stuff but nevertheless
> > > missing the corresponding automatically generated API docs in the
> > > package. That's a pity. And that's something the policy should address.

> > Hmm, I don't agree that it needs to be addressed in policy, FWIW.

> Fair enough, but note that having man pages is actually addressed by the
> policy. Why do you think API doc shouldn't? After all man pages are docs
> for users and API doc are too, with the only difference that in the
> latter case the "users" are programmers.

If I thought putting it in policy would significantly improve the
availability of API docs in Debian, I would support doing so.  But I don't
think this will happen, and anyway if people want to campaign for improving
our API documentation they can do that in any number of ways without asking
for it to be put in policy first.

Cheers,
-- 
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/


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

Re: should an init-script print output, if verbose is set to no in /etc/default/rcS or by /lib/init/vars.sh?

[Steve Langasek]

On Sat, Apr 28, 2007 at 11:23:28PM +0200, Marc Haber wrote:
> On Wed, 18 Apr 2007 03:17:43 -0700, Steve Langasek <[EMAIL PROTECTED]>
> wrote:
> >Further, why should individual init scripts that are already going to all
> >the effort of using the LSB interfaces be expected to handle VERBOSE
> >individually?  Why isn't this part of the log_* implementation?

> The LSB init script stuff is a red herring anyway since the Interface
> is badly designed and utterly incomplete. Init scripts are therefore
> forced to abuse the provided functions if something "special" is
> needed.

I agree that it's badly designed, but when so many packages are using the
Debian LSB init script functions *anyway*, why should each of these packages
be expected to individually implement a 'quiet' mode when this is clearly
something that the log_* functions should do already?

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


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

Re: Mandatory -dbg packages for libraries? (and API docs too)

[Russ Allbery]

Stefano Zacchiroli <[EMAIL PROTECTED]> writes:

> Fair enough, but note that having man pages is actually addressed by the
> policy. Why do you think API doc shouldn't? After all man pages are docs
> for users and API doc are too, with the only difference that in the
> latter case the "users" are programmers.

In my case, because of:

binary-without-manpage (1283 packages, 3616 tags)

I think we should demonstrate our ability to deliver on tasks we've
already promised to do before promising to do even more in the same vein.
Good library API documentation is in many cases much harder to write than
a man page for a binary.  Many of those already diagnosed missing man
pages are a matter of a few minutes to write a brief man page for a
wrapper script or simple utility.

-- 
Russ Allbery ([EMAIL PROTECTED])   


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

Re: pbuilder + local backports question

[Loïc Minier]

On Sun, Apr 29, 2007, Nikita V. Youshchenko wrote:
> pbuilder-satisfybuilddeps is not smart enough to try packages from 
> repository with lower pin-priority, even if build-depends is versioned. It 
> just installs default version, without any notice.

 Completely correct; but there are two other flavors of
 pbuilder-satisfybuilddeps which you can configure via
 PBUILDERSATISFYDEPENDSCMD in pbuilderrc which are
 pbuilder-satisfydepends-experimental (which will try the default
 candidate APT version first, then all versions in increasing order for
 each build-deps), and pbuilder-satisfydepends-aptitude, which is still
 very young but can deal more easily with complex cases (and very fast).

 This is more or less covered in the pbuilder documentation, in the
 pbuilding for experimental section.

   Bye,
-- 
Loïc Minier


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

Bug#421428: ITP: commons-openpgp -- a common and simple Java interface for generating and verifying OpenPGP signatures

[Paul Cager]

Package: wnpp
Severity: wishlist
Owner: Paul Cager <[EMAIL PROTECTED]>

* Package name: commons-openpgp
  Version : svn 533437
  Upstream Author : Brett Porter, Stefan Bodewig
* URL : http://jakarta.apache.org/commons/sandbox/openpgp/index.html
* License : Apache V2
  Programming Lang: Java
  Description : a common and simple Java interface for generating and 
verifying OpenPGP signatures

Commons OpenPGP was started to produce a common and simple interface for
generating and verifying OpenPGP signatures.

Currently implemented using BouncyCastle, it is intended to allow
pluggable providers so that alternate open source and commercial
providers can be used.

The library was started by Maven and Ant committers to enable the use of
OpenPGP from these tools. Currently, Maven uses it in its development
version to sign libraries released to the repository.


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

Re: Bug#421107: ITP: torbutton -- iceweasel/icedove extension enabling 1-click toggle of Tor usage

[Stephen Gran]

This one time, at band camp, Ron Johnson said:
> On 04/28/07 13:28, Greg Folkert wrote:
> > On Sat, 2007-04-28 at 15:45 +0900, Charles Plessy wrote:
> >> Le Thu, Apr 26, 2007 at 04:16:29PM +0200, Jérémy Bobbio a écrit :
> >>> Package: wnpp
> >>> Severity: wishlist
> >>> Owner: "Jérémy Bobbio" <[EMAIL PROTECTED]>
> >>>
> >>> Torbutton is a 1-click way for Iceweasel/Icedove users to enable or 
> >>> disable the
> >>> browser's use of Tor.
> >> Hi,
> >>
> >> maybe you can remind what Tor is ?
> > 
> > http://tor.eff.org/
> 
> Full Descriptions usually (should) still have such a blurb in them.

We don't need to describe in excrutiating detail every aspect of every
package.  If someone doesn't know what Tor is, they're probably not the
target audience, in the same way that you don't have to have an RFC like
description of snmp to know that snmpwalk is not the package you're 
looking for.

I agree that where possible, we should be clear in the package
descriptions.  However, given that some subset of software is aimed at
a fairly esoteric userbase, pretending that it's intended for general
use is fairly silly.
-- 
 -
|   ,''`.Stephen Gran |
|  : :' :[EMAIL PROTECTED] |
|  `. `'Debian user, admin, and developer |
|`- http://www.debian.org |
 -


signature.asc
Description: Digital signature

Re: Bug#421107: ITP: torbutton -- iceweasel/icedove extension enabling 1-click toggle of Tor usage

[Ron Johnson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 04/28/07 19:58, Stephen Gran wrote:
> This one time, at band camp, Ron Johnson said:
>> On 04/28/07 13:28, Greg Folkert wrote:
>>> On Sat, 2007-04-28 at 15:45 +0900, Charles Plessy wrote:
 Le Thu, Apr 26, 2007 at 04:16:29PM +0200, Jérémy Bobbio a
 écrit :
> Package: wnpp Severity: wishlist Owner: "Jérémy Bobbio"
> <[EMAIL PROTECTED]>
> 
> Torbutton is a 1-click way for Iceweasel/Icedove users to
> enable or disable the browser's use of Tor.
 Hi,
 
 maybe you can remind what Tor is ?
>>> http://tor.eff.org/
>> Full Descriptions usually (should) still have such a blurb in
>> them.
> 
> We don't need to describe in excrutiating detail every aspect of
> every package.  If someone doesn't know what Tor is, they're
> probably not the target audience, in the same way that you don't
> have to have an RFC like description of snmp to know that
> snmpwalk is not the package you're looking for.

Codswallop!

Asking for a blurb describing Tor can not remotely be interpreted as
wanting "excrutiating detail (of) every aspect of" Tor.

Something simple like this blurb is all that is needed:

Tor helps to anonymize your internet usage.

> I agree that where possible, we should be clear in the package 
> descriptions.  However, given that some subset of software is
> aimed at a fairly esoteric userbase, pretending that it's
> intended for general use is fairly silly.

More (this time elitist) codswallop.

- --
Ron Johnson, Jr.
Jefferson LA  USA

Give a man a fish, and he eats for a day.
Hit him with a fish, and he goes away for good!

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

iD8DBQFGM/XyS9HxQb37XmcRAl9sAJ9S5+jg9hsyuF8p0lmUlgv2AXbBWwCfcENr
CGkNXV2rCa/rOUtSStAFgBA=
=2D6E
-END PGP SIGNATURE-


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

Re: pbuilder + local backports question

[gregor herrmann]

On Sun, 29 Apr 2007 01:09:54 +0400, Nikita V. Youshchenko wrote:

> In most cases, I want all build-deps to be installed from etch.
> However, sometimes some particular packages are wanted from other 
> repository (where previously build backports are located).

If I understand correctly you want to use some packages from a local
repository/directory. If yes pbuilder can do this; take a look at
file:///usr/share/doc/pbuilder/pbuilder-doc.html#usingspecialaptsources

Cheers,
gregor
-- 
 .''`.   http://info.comodo.priv.at/ | gpg key ID: 0x00F3CFE4
 : :' :  debian: the universal operating system - http://www.debian.org/
 `. `'   member of https://www.vibe.at/ | how to reply: http://got.to/quote/
   `-NP: Janis Joplin: Summertime


signature.asc
Description: Digital signature

Re: Disable ipv4 fragmentation

[Thomas Bushnell BSG]

On Tue, 2007-04-24 at 17:39 +, J HU wrote:
> Dear experts,
> 
> I'm working with sockets in a debian with a version of kernel 2.6.x, and I'd 
> like to disable the fragmentation of the ipv4 introduce.
> I have read that there was the option of modified the file 
> /proc/sys/net/ipv4/ip_always_defrag but it doesn't exist.
> So I'm totally lost and I need to disable that fragmentation or change the 
> size to the maximum of 65535.
> Anyone can help me?

Fragmentation is part of IP.  Changing the MTU does not prevent
fragmentation.  Routers and everything in between is permitted to
fragment traffic.

You can set the DF (don't fragment) bit in various ways, but the result
is that routers which need to fragment will instead drop your packets.
IP guarantees that "small enough" packets can be transmitted without
fragmentation, but that limit is a part of the protocol and not
something you can configure.

What is the problem you are trying to solve?

Thomas



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