Which are the permitions for /dev/tty?
Hi. I seem to have a little trouble with pgp/gpg and /dev/tty permitions. My /dev/tty device was like this: << root:/dev $ ls -l tty crw-r--r-- 1 root sys5, 0 Mar 6 17:26 tty root:/dev $ >> And pgp/gpg were breaking with permitions errors with /dev/tty. So tried this: add my account to the group 'sys', and changing /dev/tty to be group write, like this: << root:/dev $ ls -l tty crw-rw-r-- 1 root sys5, 0 Mar 6 17:26 tty root:/dev $ >> Now, everything works, but I'm not very convinced that this is the right way to work thing out. BTW, I'm using kernel 2.2.2-ac7, but I've tried this 2.0.35, 2.0.36, 2.2.1, 2.2.2-ac4 and it gives the same result with all of them. Can anybody out there just reasure that this is ok, _or_ if this is not ok, then just give any ideia as to what might be happening? Thanks -- Pedro Guerreiro (aka digito)([EMAIL PROTECTED]) Diplomacy: the art of letting someone have your own way.
creating libraries
Hi.
While creating a library, one question poped to mind:
I've got a dir called cgraph-2.04, and when I run dh_make in it, it debianized
the source tree (so far so good), but the debian/control file, is like this:
-*-
Source: cgraph
Section: devel
Priority: optional
Maintainer: Pedro Guerreiro <[EMAIL PROTECTED]>
Standards-Version: 2.4.0.0
Package: cgraph1-dev
Architecture: any
Depends: cgraph1, libc6-dev
Provides: cgraph-dev
Conflicts: cgraph-dev
Description: Missing
Missing
Package: cgraph1
Architecture: any
Depends: ${shlibs:Depends}
Description: Missing
Missing
-*-
Why does the Package names have a _1_ in them? Shouldn't it be cgraph-dev and
cgraph? If the _1_ is the version of the library, them should it be _2_ (since
the library is 2.04)? (Remenber to RTFM, wait a minute...)
(...back again)
I think the _1_ is supposed to be the soname that the debian policy talks
about, but then it definitely should be _2_, right?
OTOH, why is package cgraph1-dev referring to cgraph-dev? This package doesn't
exist. Is he trying to 'create' a virtual package? I think I should delete
those lines, am I right?
Thanks.
--
Pedro Guerreiro (aka digito)([EMAIL PROTECTED])
Diplomacy: the art of letting someone have your own way.
How much pristine should the .orig.tar.gz be?
Hi. [Sorry for the cross-posting] My problems is as follows: I've debianized a library that was conceived for the NeXT in the first place, and the source code come with some utils that don't have a clear free license. The library by itself is public domain, but those utils might cause problem if I intent to put the library in main. My question is: The binary packages _will not_ have anything from those utils (they're only good in a NeXT), so there is no problem with them, _but_ the source tarball, if I make it pristine, will have those utils on it. Should I just remove the utils from the source, making the problem disappear, or keep them there and wait that -legal give permission to do so (there might be problem to this, as I understand it from a previous post from -legal)? Just remember that those utils don't serve any purpose except wasting space! :) As an attach goes the README taken from one of the utils (The other is just code, none whatsoever docs). -- Pedro Guerreiro (aka digito)([EMAIL PROTECTED]) Diplomacy: the art of letting someone have your own way. See the manpage for further details on what `open' is and what it can do for you (to have a quick look at the manpage, you may issue the following command in a shell: `nroff -man open.1 | more') Please note that this project has absolutely no relation to NeXT! Installation: If you have received the binary package (open.x.y.NI.b.pkg) you can install open with Installer.app. This procedure will install the binary (open), several links to it (appopen, unhide, run, Edit and Emacs[1]) and manpages for open, appopen, unhide and run. If you have received the source package you can either use ProjectBuilder to install open or issue the following command in a shell: `make install' This will install the binary (open) and its manpage. To install the above mentioned links and other manpages, you will need to build the `installextras' target. To do so, either add a target `installextras' in ProjectBuilder or use the following command in a shell: `make installextras' If you use a newer version of tcsh, you may want to include these lines in your `.tcshrc'. These will change the behavior of the listing and file-completion in tcsh. You will need to customize the list of hosts you want to use together with -NXHost. (substitute 'host1 host2') set nexthosts= (host1 host2) set nextapps=`/bin/ls -1 ~/Apps /LocalApps /LocalDeveloper/Apps /NextAdmin /NextApps /NextDeveloper/Apps /NextDeveloper/Demos |& grep '\.app$' | sort -u | sed 's/\.app$//g' ` completeappopen 'p/1/$nextapps/' 'n/-a/$nextapps/' 'n/-NXHost/$nexthosts/' 'c/-/(a o p NXHost unhide nostat wait temp)/' 'n/*/f/' completeunhide 'p/1/$nextapps/' 'n/-a/$nextapps/' 'n/-NXHost/$nexthosts/' 'c/-/(a o p NXHost unhide nostat wait temp)/' 'n/*/f/' completerun 'p/1/$nextapps/' 'n/-a/$nextapps/' 'n/-NXHost/$nexthosts/' 'c/-/(a o p NXHost unhide nostat wait temp)/' 'n/*/f/' completeopen 'n/-a/$nextapps/' 'n/-NXHost/$nexthosts/' 'c/-/(a o p NXHost unhide nostat wait temp)/' 'n/*/f/' Distribution: open must only be distributed free of charges. (for other ways of distribution you have to get my written consent) You are only allowed to distribute unmodified copies of this software. You may distribute modified copies if you unmistakably mark them as such. You are only allowed to distribute this software in a bundle (compressed tar archive or any other archiving/compressing method with similar purpose) including all files that are part of this software package (open.m open.h open.1 open.info appopen.1 Makefile Makefile.postamble Makefile.preamble PB.project) Warranty: - Limited Warranty: This software is provided 'as is' without warranty of any kind, either expressed or implied, including, but not limited to, the implied warranties of merchantability and fitness for a particular purpose. The entire risk as to the quality and performance of the program is with you. Should the program prove defective, you assume the cost of all necessary servicing, repair or correction. - No Liability For Consequential Damages: In no event will Christian Limpach, anyone who was involved in the creation or who redistributed the program as permitted, be liable to you for damages, including any general, special, incidental or consequential damages arising out of the use or inability to use the program (including but not limited to loss of data being rendered inaccurate or losses sustained by your or third parties or a failure of the program to operate with any other pr
Policy about library package names
Hi all.
After a couple of talks with Josip Rodin, I came across with one question
regarding the Debian Policy for naming library packages:
Suppose I've got a library named foo version 1.32, should the package name
be foo1{-dev} or libfoo1{-dev}? The question is should one use _lib_ on the
library name?
Almost all the new packages are naming the libraries lib{-dev},
but as I read it, there's nothing in the policy (section 4.3) that states this.
All it says is that the package should be called {-dev}.
Should we consider a change in the policy about making this a policy standart,
as everyone is following these rules?
--
Pedro Guerreiro (aka digito)([EMAIL PROTECTED])
Diplomacy: the art of letting someone have your own way.
Re: Policy about library package names
Opps. I wanted to mail it to -policy and it went this way. :-) Sorry. -- Pedro Guerreiro (aka digito)([EMAIL PROTECTED]) Diplomacy: the art of letting someone have your own way.
Re: How much pristine should the .orig.tar.gz be?
On Thu, Apr 01, 1999 at 11:10:35AM -0600, John Hasler wrote: > BTW, you say that the library is "public domain". What exactly does the > license say? See the reply in -legal. -- Pedro Guerreiro (aka digito)([EMAIL PROTECTED]) Diplomacy: the art of letting someone have your own way.
Re: How much pristine should the .orig.tar.gz be?
On Thu, Apr 01, 1999 at 11:10:35AM -0600, John Hasler wrote: > BTW, you say that the library is "public domain". What exactly does the > license say? See the reply in -legal. -- Pedro Guerreiro (aka digito)([EMAIL PROTECTED]) Diplomacy: the art of letting someone have your own way.
Policy about man pages for GNOME programs
As the GNOME programs provide help outside man (using GNOME system), what should I do about the packages that do not provide man pages? I've seen that the GNOME apps have a link to the undocumented man page, but that page says that a bug has been submited. Searching the bug database I've found nothing. Should we submit a bug about the man page to those packages (as 'man gmc' says) or whould we just ignore it, as the help system is provided by GNOME. Thanks. -- Pedro Guerreiro (aka digito)([EMAIL PROTECTED]) Diplomacy: the art of letting someone have your own way.
Re: CVS and packages
On Wed, Apr 21, 1999 at 11:01:17AM +1000, Chris Leishman wrote: > > I was wondering if someone could give me an breif overview of using CVS with > package source? > > I have tried to figure out the cvs-buildpackage tools, but their really > confusing. > > I want to take some original source, put it into cvs, and then debianize it. > How can this be done? In the Developer's Corner page (http://www.debian.org/devel) there is a reference to a HOWTO-CVS. -- Pedro Guerreiro (aka digito)([EMAIL PROTECTED]) Diplomacy: the art of letting someone have your own way.
Updating packages before being developer
Hi. I'm not yet a developer (shouldn't take long, I've already got a reply from the New Maintainers Group), but I got already a couple of packages, and I'm working on those packages, i.e., fixing bugs, packaging new releases, etc. I'm wondering what will happen when I try upload the new packages to master? Some are not -1 version anymore, and some already have newer upstream versions, meaning that the changelog are not the usual "* Initial Release" anymore. Do you think that will be a problem when I made the upload? -- Pedro Guerreiro (aka digito)([EMAIL PROTECTED]) Diplomacy: the art of letting someone have your own way.
Re: Updating packages before being developer
On Mon, Apr 26, 1999 at 09:56:49PM -0400, Mitch Blevins wrote:
>
> It is okay to not have a virgin package when your first upload it.
> The only issue is that is your package is not -1, then you must take
> care to ensure that the source file (orig.tar.gz) is also uploaded.
> I believe that dupload will omit it from -2 and higher packages by default.
I don't think dupload will complain, the problem is {dpkg}{cvs}-buildpackage.
But I'll make a last build using the -sa option when I ready to upload the
packages, and that (I believe) will solve any problems.
Thanks for all the comments guys.
--
Pedro Guerreiro (aka digito)([EMAIL PROTECTED])
Diplomacy: the art of letting someone have your own way.
Re: creating libraries
On Thu, Apr 01, 1999 at 12:16:23AM +0200, Josip Rodin wrote:
> On Wed, Mar 31, 1999 at 10:57:10PM +0100, Pedro Guerreiro wrote:
> > > If they are libraries, they should be called lib{-dev}.
> >
> > Why? Are there any policy regarding this subject? The library is called
> > _cgraph_ not _libcgraph_, why should I rename it? There are several
> > libraries
> > that do not have the lib part (mesa and glut, just to name a couple).
>
> Yes, GTK+ is not libgtk1. Yes, XForms is not libforms0.88. Yes, FLTK is
> not libfltk1. Yes, GGI is not libggi2. Yes, ncurses is not libncurses4.
> Yes, PAM is not libpam0. Yes, PropList is not libproplist0. Yes, ReadLine
> is not libreadline2.
Don't need to came so hard, I was just making a question (and a good one too,
IMHO :-) ).
> Why? Read Debian Policy, section 4.3.
I've read, re-read, tri-read, ... and still don't quite get it.
I says there that the library should be called , but that
is not the same as lib, or is it?
Ok, just let me make clear that I don't have any problem making the library
name libcgraph instead of just cgraph, I just want to make a point.
I can see that the _normal_ way to build the libraries these
days is to use lib, and all the new stuff is following these
paths, as one can see by the examples you give above _but_, as I read it, the
Debian Policy _does not_ makes you do so.
How about changing the policy to make this fact perfectly clear? If we replace
by lib then there should be no more doubts
to anyone.
> > But don't I need to discuss it (in -devel I think) to create a virtual
> > package?
>
> Yes, that is the problem, actually, because you usually need to have a
> good reason to have a virtual package. Better ask on debian-devel.
I don't think it's worth the trouble. I _don't_ have a good reason to create a
virtual package. The library is pretty much useable and stable.
--
Pedro Guerreiro (aka digito)([EMAIL PROTECTED])
Diplomacy: the art of letting someone have your own way.
Re: What happened to new-maintainer@debian.org
On Mon, May 10, 1999 at 02:07:04PM +0200, Norbert Nemec wrote: > Hi there, > > does anybody know, why I do not get any response for my application to the > above address? I sent the first application containing all the data ~4weeks > ago, resent it ~2 weeks ago and sent another mail couple days ago, but I did > not get any reaction. The mail did not bounce, so I suppose, the address is > correct. > > I know those guys may be quite busy, but after taht time I would just like to > know somebody read my mail. Ok, first, do not EVER EVER resent your application. If you must, sent a mail asking what's up. Second, take it easy, be a good boy :) and be ready to wait a couple of months. >From my experience: I sent my application ~3 months back and I've received a mail saying that my application was going to be processed a couple of weeks ago. Right now I'm just waiting to receive a phone call from James (I'm been very busy these last weeks or I would give him a call). OTOH, from what I've head around, one of the main reasons for this delay on processing the applications (apart from the lack of time, of course) is that everybody wants their application to be processed quickly, but then they don't do nothing for a few months. In these cases, where's the rush? I think that all wannabe developers should first start working on their new/adopted/whatever packages, and only then send their applications. In my personal case, I've got my packages gattering dust :) on my site. When I became a Developer its just a matter of uploading to master. -- Pedro Guerreiro ([EMAIL PROTECTED]) Diplomacy: the art of letting someone have your own way.
Re: new maintainers
On Fri, Dec 31, 1999 at 10:28:01AM -0700, Bob Nielsen wrote: > On Fri, Dec 31, 1999 at 10:51:40PM +0900, Taketoshi Sano wrote: > > Hi. > > > > I joined Debian at May 23, this year (1999). I know at least one > > new maintainer who joined at June, IIRC. Old New Maintainer Team > > did work at that time. > > You must have squeaked in under the wire. I applied in late May or > early June (I forget the exact date and my old sent-mail files have > been erased), got the automated response and since then there has been > silence (other than the flames on the mailing lists). The earliest > message I saw complaining about a lack of response was dated June 11. I've applied in March 6, and go two responses in April 25: one was the (not so) automated response, and the other was a reply from James. Since then, I guess I'm just waiting... In the meantime, I package some stuff, and I'm still looking for a sponsor to them (hint, hint). There are two packages that I think should be useful to potato: glilo (a gtk+ configuration utility for lilo) and pharmacy (a gnome front-end to cvs). For anyone interested, they can be found on http://w3.ualg.pt/~pmguerre. thanks. -- Pedro Guerreiro ([EMAIL PROTECTED]) Diplomacy: the art of letting someone have your own way.
Re: new maintainers
On Sat, Jan 01, 2000 at 11:47:52PM +, Pedro Guerreiro wrote: > In the meantime, I package some stuff, and I'm still looking for a sponsor > to them (hint, hint). There are two packages that I think should be useful to > potato: glilo (a gtk+ configuration utility for lilo) and pharmacy (a gnome > front-end to cvs). For anyone interested, they can be found on > http://w3.ualg.pt/~pmguerre. opps, just remember that this page is very old :(, and only mentions three of the packages. You'd better try http://w3.ualg.pt/~pmguerre/debian for all the packages. BTW, I've got pharmacy 0.2.1 (the lastest version) packaged, and if anyone interested in sponsor it for potato, I'll upload it. -- Pedro Guerreiro ([EMAIL PROTECTED]) Diplomacy: the art of letting someone have your own way.
New .deb's of pharmacy available
Hi. I've packaged the new version of pharmacy (0.2.1a), and they can be found on http://w3.ualg.pt/~pmguerre/debian/pharmacy The pharmacy home page can be found on http://pharmacy.sourceforge.net For those unfamiliar with pharmacy, it's a GNOME frontend to CVS. It's still under development, but it's okish to work with. As a "Long Standing Waiting To Be"(tm) Debian Developer, I'm also searching for a sponsor to this package. Thanks. Pedro Guerreiro
Lintian report that man pages are not compressed with --best
Hi.
How does lintian (or I) see if a man page is compressed with the --best
option?
Right now it seems that there is an error somewhere. Let me explain: when
packaging greed, lintian reported that the man page was not compressed with
the --best option. Ok, I've decompressed it and compressed again with this
switch, and it gave the same error. What the $%&#?
However, if I do this 'gzip -dc greed.1.gz | gzip -9 > greed.1.gz' lintian
does not report any error, and the compressed file is 8 bytes shorter
(AFAICT, this happens because this way the name of the file is nor recorded
in the compressed file). Also, if I decompress the file, and leave it up to
debhelper to compress the file, lintian reports no error, and the file is
the same size as the original one (the one that lintian complained before).
Can somebody explain or give any suggestion as to what is happening?
I've attached this three files to this post:
-rw-r--r--1 digito users1091 May 1 21:38 greed-pipe.1.gz
-rw---1 digito users2205 Jan 20 18:31 greed-uncomp.1
-rw-r--r--1 digito users1099 Apr 25 23:45 greed.1.gz
greed.1.gz - Original file: lintian complains about this file
greed-pipe.1.gz - Obtained with gzip -dc greed.1.gz | gzip -9 > greed-pipe.1.gz
lintian clean
greed-uncomp.1 - Decompressed file: lintian clean
FWIW:
-==-==-
ii lintian1.11.2 Debian package checker
ii gzip 1.2.4-33 The GNU compression utility.
ii debhelper 2.0.86 helper programs for debian/rules
Does anybody know what's going on?
Thanks.
--
Pedro Guerreiro UIN: 48533103
Universidade do Algarve (EST) - Campus da Penha - 8000 Faro - PORTUGAL
GPG: 0xCF32D4E7F506 DDF4 0B92 247D B8E6 13BA A6DB 9E3A CF32 D4E7
greed.1.gz
Description: Binary data
greed-pipe.1.gz
Description: Binary data
'\"
'\" greed 1
'\"
.TH greed 1 "" greed "\fBG\fRet and \fBR\fResume \fBE\fRlite \fBED\fRition"
.BS
'\" Note: do not modify the .SH NAME line immediately below!
.SH NAME
greed \- Lets you get and resume files.
.SH SYNOPSIS
\fBgreed [-sn] [-o{0..1}] [URL0 URL1..URLN]
.BE
.SH DESCRIPTION
.PP
Greed lets you download and resume files from web and FTP sites.
.SH OPTIONS
.TP
.BR \fB-?\fR
Brings up quick help
.TP
.BR \fB-z\fR
Sends a bug report to me
.TP
.BR \fB-t\fR
Tests the file if it is a valid archive after the download is finished
.TP
.BR \fB-s\fR
Prints the file downloaded to STDOUT
.TP
.BR \fB-r || -rURL\fR
Turns off the http referrer and changes the referrer to URL,
respectively
.TP
.BR \fB-o{0..9}\fR
0..9 is the level of output GREED prints
.TP
.BR \fB-n\fR
Downloads the newest version of GREED
.TP
.BR \fB-mADDRESS\fR
Sends an e-mail to ADDRESS every time greed downloads a file (-t MUST
be used)
.TP
.BR \fB-l#\fR
Sets the level of recursion (how many directories down greed should go
on an FTP site)
.TP
.BR \fB-i\fR
Reads URLs from Standard Input
.TP
.BR \fB-gfilename.grx\fR
Loads a .grx file (Windows GetRight), parses it, and downloads the
files specified within
.TP
.BR \fB-f\fR
Disables reading URLs from greed.in
.TP
.BR \fB-d#\fR
Tells greed to download X files at a time. If no number is specified,
it assumes 2 at a time.
.TP
.BR \fB-cURL\rR
Changes the %##'s in a URL to characters... should old be used for
URL's that don't work correctly, or have %##'s in them ;)
.TP
.BR \fB-b\fR
Sends GREED into background download mode.
.SH COOL TIPS
.TP
\fBgreed -i < files.to.download\fR
Lets you download all the files in files.to.download
.TP
\fBgreed -d -b http://foo.bar/file.zip http://ab:[EMAIL PROTECTED]/kl/mno.p\fR
Drops greed into the background and downloads the 2 URLS
simultaineously!
.TP
\fBgreed -b -t [EMAIL PROTECTED] -l ftp://ftp.cdrom.com/\fR
Sends e-mails on each successful download and downloads
ftp.cdrom.com... and I mean all .5 terrabytes :) Give it a try ;)
.TP
\fBgreed www.freshmeat.net...freshmeat.index.html\fR
"..." saves the URL retrieved from www.freshmeat.net to
freshmeat.index.html
.SH KEYWORDS
resume download ftp www
Re: Lintian report that man pages are not compressed with --best
On Mon, May 01, 2000 at 05:10:04PM -0700, Darren Benham wrote: > Is --best the same as -9? They are, at least according to gzip man page: -- snip -- -# --fast --best Regulate the speed of compression using the speci fied digit #, where -1 or --fast indicates the fastest compression method (less compression) and -9 or --best indicates the slowest compression method (best compression). The default compression level is -6 (that is, biased towards high compres sion at expense of speed). -- snip -- -- Pedro Guerreiro UIN: 48533103 Universidade do Algarve (EST) - Campus da Penha - 8000 Faro - PORTUGAL GPG: 0xCF32D4E7F506 DDF4 0B92 247D B8E6 13BA A6DB 9E3A CF32 D4E7
Problems with shared lib (-fPIC)
Hi. I'm having problems compiling a shared python extention, because lintian keeps complaining about foo.so not being compiled with the -fPIC option, but IT IS, as you can see from the output: --- cut --- Making all in compiled make[3]: Entering directory /home/digito/debian/devel/pybliographer/pybliographer/compiled' gcc -fPIC -I/home/digito/debian/devel/pybliographer/pybliographer/./compiled/../bibtex -I/usr/lib/glib/include -I.. -g -O2 -I/usr/include/python1.5 -I/usr/include/python1.5 -DHAVE_CONFIG_H -c /home/digito/debian/devel/pybliographer/pybliographer/./compiled/bibtexmodule.c gcc -shared -lc bibtexmodule.o ../bibtex/.libs/libbibtex.a -L/usr/lib -lglib -lrecode -o _bibtexmodule.so gcc -fPIC -I.. -g -O2 -I/usr/include/python1.5 -I/usr/include/python1.5 -DHAVE_CONFIG_H -c /home/digito/debian/devel/pybliographer/pybliographer/./compiled/recodemodule.c gcc -shared -lc recodemodule.o -lrecode -o _recodemodule.so make[3]: Leaving directory /home/digito/debian/devel/pybliographer/pybliographer/compiled' --- cut --- Is this a bug in lintian, or am I doing something wrong? -- Pedro Guerreiro UIN: 48533103 Universidade do Algarve (EST) - Campus da Penha - 8000 Faro - PORTUGAL GPG: 0xCF32D4E7F506 DDF4 0B92 247D B8E6 13BA A6DB 9E3A CF32 D4E7
