Re: Sun RPC libraries and other stories

[Florian Weimer]

* Simon Phipps:

> On Nov 5, 2008, at 23:23, Michael Banck wrote:
>>
>> - portmap.c
>>
>> /*
>> @(#)portmap.c   2.3 88/08/11 4.0 RPCSRC
>> static char sccsid[] = "@(#)portmap.c 1.32 87/08/06 Copyr 1984 Sun
>> Micro";
>> */
>>
>> This is portmap-6.0, from http://neil.brown.name/portmap/
>
> Is this in any way related to any Sun code, or is the string simply
> used by the author for external reference in some way?

It seems that the code was released by the Portable NFS group at Sun
in 1987:

  

(portmap.c is in etc.  Ah, those were the times!)

The distribution above was apparently intended for use on 4BSD.  This
might explain why it does not match a code base derived from SunOS 5.

An announcement of the release was re-posted to Usenet in a digest
with message ID <[EMAIL PROTECTED]>.


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

Re: Sun RPC libraries and other stories

[Florian Weimer]

* Simon Phipps:

> On Nov 18, 2008, at 03:52, Ben Hutchings wrote:
>
>> Many of the functions in portmap.c seem to correspond to
>> rpcbind (usr/src/cmd/rpcbind) in OpenSolaris:
>
> Is it just the function prototypes that are derived, or is there
> derived source defining them too?

>From our portmap.c:

| /*
|  * Stuff for the rmtcall service
|  */
| #define ARGSIZE 9000
|
| struct encap_parms {
| u_int arglen;
| char *args;
| };
|
| static bool_t
| xdr_encap_parms(XDR *xdrs, struct encap_parms *epp)
| {
|
| return (xdr_bytes(xdrs, &(epp->args), &(epp->arglen), ARGSIZE));
| }
|
| struct rmtcallargs {
| u_long  rmt_prog;
| u_long  rmt_vers;
| u_long  rmt_port;
| u_long  rmt_proc;
| struct encap_parms rmt_args;
| };
|
| static bool_t
| xdr_rmtcall_args(XDR *xdrs, struct rmtcallargs *cap)
| {
|
| /* does not get a port number */
| if (xdr_u_long(xdrs, &(cap->rmt_prog)) &&
| xdr_u_long(xdrs, &(cap->rmt_vers)) &&
| xdr_u_long(xdrs, &(cap->rmt_proc))) {
| return (xdr_encap_parms(xdrs, &(cap->rmt_args)));
| }
| return (FALSE);
| }
|
| static bool_t
| xdr_rmtcall_result(XDR *xdrs, struct rmtcallargs *cap)
| {
| if (xdr_u_long(xdrs, &(cap->rmt_port)))
| return (xdr_encap_parms(xdrs, &(cap->rmt_args)));
| return (FALSE);
| }
| 
| /*
|  * only worries about the struct encap_parms part of struct rmtcallargs.
|  * The arglen must already be set!!
|  */
| static bool_t
| xdr_opaque_parms(XDR *xdrs, struct rmtcallargs *cap)
| {
| 
| return (xdr_opaque(xdrs, cap->rmt_args.args, cap->rmt_args.arglen));
| }

>From 
>:

| /*
|  * Stuff for the rmtcall service
|  */
| struct encap_parms {
|   ulong_t arglen;
|   char *args;
| };
|
| static bool_t
| xdr_encap_parms(xdrs, epp)
|   XDR *xdrs;
|   struct encap_parms *epp;
| {
|   return (xdr_bytes(xdrs, &(epp->args), (uint_t *)&(epp->arglen), ~0));
| }
|
|
| struct r_rmtcall_args {
|   ulong_t rmt_prog;
|   ulong_t rmt_vers;
|   ulong_t rmt_proc;
|   int rmt_localvers;  /* whether to send port # or uaddr */
|   char*rmt_uaddr;
|   struct encap_parms rmt_args;
| };
|
| /*
|  * XDR remote call arguments.  It ignores the address part.
|  * written for XDR_DECODE direction only
|  */
| static bool_t
| xdr_rmtcall_args(xdrs, cap)
|   register XDR *xdrs;
|   register struct r_rmtcall_args *cap;
| {
|   /* does not get the address or the arguments */
|   if (xdr_u_long(xdrs, &(cap->rmt_prog)) &&
|   xdr_u_long(xdrs, &(cap->rmt_vers)) &&
|   xdr_u_long(xdrs, &(cap->rmt_proc))) {
|   return (xdr_encap_parms(xdrs, &(cap->rmt_args)));
|   }
|   return (FALSE);
| }
|
| /*
|  * XDR remote call results along with the address.  Ignore
|  * program number, version  number and proc number.
|  * Written for XDR_ENCODE direction only.
|  */
| static bool_t
| xdr_rmtcall_result(xdrs, cap)
|   register XDR *xdrs;
|   register struct r_rmtcall_args *cap;
| {
|   bool_t result;
|
| #ifdef PORTMAP
|   if (cap->rmt_localvers == PMAPVERS) {
|   int h1, h2, h3, h4, p1, p2;
|   ulong_t port;
|
|   /* interpret the universal address for TCP/IP */
|   if (sscanf(cap->rmt_uaddr, "%d.%d.%d.%d.%d.%d",
|   &h1, &h2, &h3, &h4, &p1, &p2) != 6)
|   return (FALSE);
|   port = ((p1 & 0xff) << 8) + (p2 & 0xff);
|   result = xdr_u_long(xdrs, &port);
|   } else
| #endif
|   if ((cap->rmt_localvers == RPCBVERS) ||
|   (cap->rmt_localvers == RPCBVERS4)) {
|   result = xdr_wrapstring(xdrs, &(cap->rmt_uaddr));
|   } else {
|   return (FALSE);
|   }
|   if (result == TRUE)
|   return (xdr_encap_parms(xdrs, &(cap->rmt_args)));
|   return (FALSE);
| }
| 
| /*
|  * only worries about the struct encap_parms part of struct r_rmtcall_args.
|  * The arglen must already be set!!
|  */
| static bool_t
| xdr_opaque_parms(xdrs, cap)
|   XDR *xdrs;
|   struct r_rmtcall_args *cap;
| {
|   return (xdr_opaque(xdrs, cap->rmt_args.args, cap->rmt_args.arglen));
| }

So there's certainly some overlap, and it's not just prototypes.


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

Japanese Font Transition (step for applications)

[Hideki Yamane]

Hi,

 We - Japanese font maintainers - have finished transition from obsolete
 Kochi (東風) fonts to other Japanese fonts. And now, some packages needs
 to be fixed to deal with that. Affected packages that we have already 
 known are below.

  - libpango1.0-common
  - xpdf-japanese
  - gs-cjk-resource
  - xdvik-ja
  - vflib2
  - mgp
  - libkiten1
  - kiten
  - kanjipad
  - kanatest
  - gjiten
  - advi-examples
  - advi

 See http://wiki.debian.org/Fonts/JapanesefontpkgProposal
 We are in 3rd step "Virtual package is approved" (in unstable and testing).


 Those packages need changes (yes "CHANGE" :), such as

 * depends on ttf-japanese-gothic/mincho, not ttf-kochi-gothic/mincho
 * grep hard-corded "kochi" :-), then fix it.


 First of all, dependency fix is needed. So, maintainers, could you fix
 your debian/control file, please? or we'll to sent a bug report and patches
 for them.

 If you have a question, please ask me. Thanks.

-- 
Regards,

 Hideki Yamane henrich @ debian.or.jp/iijmio-mail.jp
 http://wiki.debian.org/HidekiYamane


pgp0OcmPt09T8.pgp
Description: PGP signature

Re: Japanese Font Transition (step for applications)

[Josselin Mouette]

Le mercredi 19 novembre 2008 à 00:43 +0900, Hideki Yamane a écrit :
>   - libpango1.0-common

Fixed in our SVN.

>  If you have a question, please ask me. Thanks.

Yes, I think there is a typo in ttf-hanazono: it provides
ttf-japanse-mincho instead of ttf-japanese-mincho.

BTW, the approach you have taken (depend on a virtual package only) will
make APT select a random font from those providing the virtual package
instead of having a sane default. You should either make ttf-japanese-*
packages that depend on the appropriate set of alternatives, or ask
people to depend on ttf-sazanami-* | ttf-japanese-* instead.

Cheers,
-- 
 .''`.
: :' :  We are debian.org. Lower your prices, surrender your code.
`. `'   We will add your hardware and software distinctiveness to
  `-our own. Resistance is futile.


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

Re: screenshots.debian.net

[Michael Vogt]

On Sun, Nov 16, 2008 at 10:12:26PM -0800, Daniel Burrows wrote:
> On Sun, Nov 16, 2008 at 07:46:27PM +0100, Christoph Haas <[EMAIL PROTECTED]> 
> was heard to say:
> > On Sonntag, 16. November 2008, Daniel Burrows wrote:
> > > On Thu, Nov 13, 2008 at 10:18:26PM +0100, Christoph Haas 
> > <[EMAIL PROTECTED]> was heard to say:
> > > > Thumbnail (<= 160x120 pixels):
> > > >   http://screenshots.debian.net/thumbnail/PACKAGENAME
> > > >   (this URL returns a dummy thumbnail if no screenshot was found)
> > >
> > >   Just one quick question: will there eventually be support for
> > > different versions to have different screenshots?  Occasionally
> > > there's a big difference across versions, and users might want to
> > > see it.
[..]
>   Oh, and a third question while I'm at it:  what sort of bandwidth is
> available for this system?  I imagine that automatically fetching
> thumbnails for an entire list of a few hundred packages would be poor
> manners.  Do you think you can handle fetching the thumbnail of each
> package the user clicks on?

I was pondering about this problem as well and solved it for now by
adding a little button into the package description in synaptic that
fetches the thumbnail when clicked. Clicking on the thumb again gives
the big image. This ensures that casual browsing of the package list
does not generate network traffic on s.d.n

I think even that will be quite a hit to screenshots.debian.net. I
imagine in the future it may make sense to have a package for this
(this was suggested already IIRC) so that the download bw is spread
over all the mirrors. 

Cheers,
 Michael


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

Bug#506151: ITP: apt-forktracer -- a utility for managing package versions

[Marcin Owsiany]

Package: wnpp
Severity: wishlist
Version: N/A; reported 2008-11-18

Package name: apt-forktracer
Upstream Author: Copyright (C) 2008 Marcin Owsiany
URL: http://marcin.owsiany.pl/apt-forktracer-page
License: GPL v2 or later
Description: a utility for managing package versions
 apt-forktracer tries to alleviate the problem that APT stops tracking
 official versions of a package after you pin it or install a newer
 version.
 .
 It displays a list of packages which are in an inconsistent state or
 have a version other than the newest official installed. You can choose
 to ignore certain packages - if they match certain criteria - with a
 configuration file.

I already announced the intent to write such program in August:
http://lists.debian.org/debian-devel/2008/08/msg00248.html

I finally completed it, and it is available for download from the
homepage. The documentation is available there as well. As I said in the
original thread, it is implemented in Python, as I wanted to learn the
language better and I thought it is more appropriate for prototyping.

I am open to suggestions for a better name. "Fork" may have negative
connotation, but I could not think of anything else that would emphasize
the fact that the program is interested in two versions at the same
time, one of which is "official".

-- 
Marcin Owsiany <[EMAIL PROTECTED]> http://marcin.owsiany.pl/
GnuPG: 1024D/60F41216  FE67 DA2D 0ACA FC5E 3F75  D6F6 3A0D 8AA0 60F4 1216



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

Re: screenshots.debian.net

[Daniel Burrows]

On Mon, Nov 17, 2008 at 10:02:45PM +0200, George Danchev <[EMAIL PROTECTED]> 
was heard to say:
> On Monday 17 November 2008 18:13:55 Daniel Burrows wrote:
> >   When the user clicks on a package in the GUI interface, they see the
> > description of the package.  I don't know what sort of load this would
> > impose once the interface is out of "beta", but I'm guessing it's a lot
> > more than you're seeing through the Web service.
> >
> >   I'd like to make good use of this service, but I don't want to turn
> > it into a smoking crater in the process. ;-) I don't really know what
> > image-fetches-per-second translates into at your end, so I guess I'm
> > looking for some guidance.
> 
> I'm afraid that such frivoulous image fetching would be magnitude or two more 
> heavier to serve than fetching the new packages for today from a local Debian 
> mirror(s), since users are more likely to performe the latter once or twice 
> per day, but the former any time they feel bored or experiencing a long long 
> day ;-)

  I don't think this is "frivolous": for programs that are graphical,
it can be very useful to see what the program looks like before you
run it.

  I'm not surprised that the bandwidth consumption is excessive,
though.  I'll think it over once I figure out why my VteTerminals
self-destruct when I hide them...

  Daniel


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

Re: screenshots.debian.net

[Martin Stigge]

On Tue, 2008-11-18 at 20:44 +0100, Michael Vogt wrote:
> I was pondering about this problem as well and solved it for now by
> adding a little button into the package description in synaptic that
> fetches the thumbnail when clicked. Clicking on the thumb again gives
> the big image. This ensures that casual browsing of the package list
> does not generate network traffic on s.d.n
>
> I think even that will be quite a hit to screenshots.debian.net. I
> imagine in the future it may make sense to have a package for this
> (this was suggested already IIRC) so that the download bw is spread
> over all the mirrors. 

Local caching may also be an option.

Regards,
Martin


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