Re: Tarball question
I've applied a few days ago as debian developer and currently waiting for being assigned an AM ;) so my answer is just my opinion, not based on much experience ;) > 1. I keep up the distinction between the two tarballs. This has > the disadvantage that I have two write two rules files etc. and > yields two orig.tar.gz. Like it was done by the previous maintainer? I consider this a good idea if the two parts might be updated independently; if i understand you correctly, there's also documentation in the first tarball - then i would prefer the following > 2. I merge the two tarballs into one, which contains the > original tarballs in two subdirectories. This would be nice > because I would need only one orig.tar.gz, and would not > increase the total size. did you look at other packages with the same problems etc.? There will surely be some out there. I also like the way xfree builds: the tarball contains the official tarball which will be extracted and patched during the build process. So i think it would be possible that you make a source tarball containing just the two upstream tarballs and a debian/rules file which extracts both tarballs into a working dir, patches them and then starts building the packages. Ths disadvantage is that if somebody wants/needs to compile mozart himself, he'll have to download more data. > 3. I build the documentation from the sources. This requires > Java, and as this is a somewhat tricky dependency, this > solution was given up some time ago. A build-dependency on java (where i do not understand why jdk1.1 could go into non-free...) which isn't inside the debian tree - that would be very ugly and worth a lot to avoid. Did you try building it with other sgml parsers? Greetings, Erich
Re: When can I include my package in stable?
Robin schrieb: > What are the conditions for a package to be included in stable? > I have looked through the policy document to find any clues on this but > I couldn't find anything. It's actually quite well described... An existing "stable" will only be changed for security and critical updates. But there will be new "stable" releases (of course). This process, called a "freeze" has just begun (see Mailing List Archives, base is freezing) During the freeze, no new features are to be added to packages, only bugs may be fixed (so hopefully no new bugs arise) After some quality testing, and after all serious bugs have been fixed, "frozen" will be released and become the new "stable". So if your package has no serious bugs (and no package it depends on has serious bugs!), it will surely be in "testing" now. It will then make it into "frozen" and thus "stable" by itself. Greetings, Erich
Re: GPG key
> This is an output of: > gpg -v -v -v -v --with-colons --list-keys porridge > > Does anyone understand anything of this mess and can provide me > with some clues on how to read it? I could not find any help in > gnupg documentation. Why use it then? ;) -veryveryveryverbose ;) > (Hint: anything that has "Marcin Owsiany" in it is me, > everything else is not me) the others are signatures. This is a colon-separated table first column is the type (pub = public key, uid= user id, sig =signature second column is "u" for user ids, pub and sub. third column is key-length in bits just compare the values with the regular output to find out their meaning. If your are wondering who the "others" are - that are signatures on the keys. Greetings, Erich
Re: Needa sponsor/advocate
> Description: Translates text files between Mac, DOS, and Unix formats > 'eol' contains 4 programs that help you deal with cross-platform text > files: >- tounix converts a text file into Unix format (eol=lf) from any format. >- tomac converts a text file into Macintosh format (eol=cr) from any > format. >- todos converts a text file into DOS format (eol=crlf) from any format. >- towin converts a text file into DOS format (eol=crlf) from any format. Do you know "recode"? recode knows over 200 different character sets and file formats and can easily be used for that. So insted of making separate programs, i'd suggest using aliases like alias dos2unix='recode dos/CR-LF..l1' alias unix2dos='recode l1..dos/CR-LF' alias unix2win='recode l1..windows-1250' Recoding isn't trivial, and your claim "from any format" won't hold for sure, as most codeset's cannot be distinguished at all. Furthermore it looks like converting to Mac isn't completely done by replacing the linefeeds with carriage returns. Windows does use a different codepage as dos, afaik! Even DOS doesn't always use the same Codepage. It usually uses 437 OR 850 though. So expect to get bugs over bugs for your package. But i don't want to warp you from becoming a Debian Packager, i'm still in the New Maintainer Process myself. I'm doing Debian Packages for a Library i found in the 'net not available for Debian yet - and learned a lot as it contains wrappers for perl, python, php (and ruby and java, but i couldn't get these to work yet...) - so my source package generates 7 binary packages, i needed to split correctly. Greetings, Erich pgprTsptt4I2g.pgp Description: PGP signature
lintian-warning copyright-lists-upstream-authors-like-dh_make
> W: prips: copyright-lists-upstream-authors-like-dh_make I've run into that warning with my packages, too. Is this really intended? Is it a bad-thing (tm) to fill out the dh_make template? i could not find this rule anymore in the lintian on the mips box i just checked, btw. So maybe this is already removed. Greetings, Erich
Re: looking for a sponsor
> Perhaps I've expressed myself a little wrong. Consider me an upstream > developer, rather than a package maintainer. (I've only created a > package since it's a little easier to install than a .tgz. If my > sponsor wants/needs to create a new package from source, that's ok > with me.) So actually you are not looking for a sponsor, but for a debian package maintainer? There might be some on the list eager to find new software to show their skills as Debian Maintainers ;) Debian Sponsorship is for upcoming debian maintainers to get their packages into the archive, while not yet being in the keyring themselves. It's not intended for People to bring their Software into the Debian Archive without being Maintainers themselves. AFAIK ;) I don't know what's the best way to do this. Maybe have someone upload the package and then do a formal "orphan" for the package; so Debian Developers will see this Package orphaned and might consider adopting the package. Greetings, Erich
Re: lintian-warning copyright-lists-upstream-authors-like-dh_make
> > You can also run lintian with the -i (or --info) flag to print these > > automatically. > > Or if you are using debuild "debuild -L -i" to see lintian error against > the source (ie: errors in debian/control) Thanks, i was just about to check the debuild manpage for that option ;) Greetings, Erich
Re: XMMS Plugins
> - For the source name, you better keep the upstream choise, so call >your SOURCE package (i.e. the source directory for the first dh_make >run) -. Just a question of procedure: What if i wanted to rename a source package? How would i do this? Not that i want to rename my package right now (it's named libming, although upstream name ist "ming" only; but as this IS a library (and a few utils for the sole use by the library) i consider this name better ;) Greetings, Erich
Re: building a sponsored package
> I think that's Maintainer: in the control file (and the .dsc). It makes > sense to me that the maintainer of a .dsc is the person primarily > responsible for the package, while the maintainer of a .changes is the > person responsible for uploading this particular build. This also The Maintainer schould always be the same, i think. Either someone maintains a package or he doesn't. > matches the fact that porters typically upload with their name in the > .changes Maintainer: field. Because they upload with the Architecture limited to what they uploaded. They are somehow the maintainer of the package for that specific architecture. for example Non-Maintainer-Uploads: the Maintainer shouldn't change - but the Changed-By: field has to get the Name of the Person doing the NMU. So i think that's straightforward. The Maintainer is "responsible" for the package, the Changed-by: responsible for his changes. More specific is the Maintainer the Contact for Requests about that package. And this is NOT the sponsor. Bugs should be adressed by the sponsored new maintainer themselves. Sponsors just review the maintainers work and do the upload. Greetings, Erich
Testing update-Excuses
> http://ftp-master.debian.org/testing/update_excuses.html.gz> says: One question to reading that page: "libming" is a "valid candidate" and is depending on libc6 only. The dependency is versioned on (>= 2.2.3-7), but libc6 2.2.4-1 is in testing. Any idea what is keeping libming out of testing? Is it php4 missing for ia64 and arm which is keeping the whole libming out of testing? Which is then held back by libtool 1.4 which is considered buggy? http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=66135&repeatmerged=yes That would be ugly that the whole lib cannot enter testing, because of the php4 part. :-( Greetings, Erich
Re: How granular should a package{,set} be?
Well, i think the basic principle is "split everything that people might want to install independantly or that can be upgraded independantly" So i think it's a good idea to enable people to install most parts of your suite, but leave the httpd away (if they want to use some other httpd etc.) I don't think the -docs package should Recommend any non-docs package. Many people will install your kit on one machine, the docs on another. But p.e. it makes sense that libgnome-doc recommends libgtk-doc FYI: The first thing that came into my mind, when i read about your package, was "oh, another proxy" and "is that really really secure". It scares me a bit that you include even an httpd server (which have to do a lot of security checks)... Why not use existing, audited software? There are small httpd servers, what's wrong with them? Same for the httpd proxy: If i look at squid, a proper caching httpd proxy with good performance is a LOT of work, why not use squid? And if squid is lacking some features etc. create a spin-off project from squid with a few "squid-veterans" which have learned from their mistakes with squid. Same for all other parts of your software. Just the 2¢ that came into my mind, i haven't looked at your code at all, these are just prejudices to any new software having more parts than developers. Greetings, Erich P.S. There is no pseudo package httpd or web-server provided by apache? We've got quite a few httpd's (roxen, boa, dhttpd wn) so maybe two web-server and web-server-cgi pseudo packages would be a good idea?
Re: How granular should a package{,set} be?
> The "upgraded independantly" is a good point. As an > in-development package, I wouldn't at the point be > entirely happy with people running older versions if > they wanted stability. You can use versioned Depends for that, if that is necessary. If not necessary, don't do this. But during heavy development, versioned depends are ok (if you don't know yet that they play together well) But don't expect people to run different versions ;) expect them to upgrade every day, because lot's of debian unstable users do have the "upgraditis" virus ;) What i meant is p.e. splitting of data from program code. So a game putting the sound data files, graphics, levels and binaries into separate packages can be very useful: people will (might) have to download the binary and level packages only for an upgrade. or someone might do a "other levels" package, providing a different level set for the same game. --[ so back to off-topic ]-- i don't want to stop you from doing this. Good additional proxies would be great. But better do one proxy right than 10 proxies insecure. That's what scares me most: you want to do everything. Next you want to do traffic shaping as well (which is a pain in the ass, even with the tc tool, but even more by doing rtnetlink yourself... but the possibilites are great...) next step is then writing the tcp stack yourself. In Security, it is most important to have secure and reliable features, quantity is much less important than quality. But remember: don't let me discourage you. Especially this discussion is independant of the Debian packages, i'm not even yet a maintainer myself. > "another proxy"? Please point me to a decent, non-abandoned, > Free software proxy firewall kit. I know only of Zorp, and "Proxy Suite" from SuSE? I think they have released only ftp yet, though... and the homepage disappeared during the redesign :-( Than i've seen the "falcon firewall project" there might be even more. "Astaro Security Linux" is a linux distribution with your goals i think. Ok, none of them is as complete (or aims to be, i think) as yours. > As to the security aspects, I'd much rather you didn't make > such implications without at least having a look for yourself. i'm just afraid of security holes; but that's why i stated this was just what came into my mind first: i wanted to state that i didn't do so. > One of my design goals is that it be possible to audit the kit > merely by reading the source through once. The code isn't that does sound great ;) > Please point me towards an existing, audited, maintained, > free software ftp gateway. Or a nice, unified, access- Just to give a few existing, mostly maintained and quite some audited proxy servers for differen protocols: ftp-proxy: ftp proxy server from SuSE jftpgw: ftp proxy / gateway perdition: pop3 and imap4 proxy server oops: http caching proxy server squid: http caching proxy server tinyproxy: http proxy server muffin: personal http proxy (like rabbit, wwwoffle, filterproxy, junkbuster) socks4-server: socks server tsocks: transparent socks proxy dante: socks server smtpd: mail proxy for firewalls plum: irc proxy madoka: irc proxy dircproxy: irc proxy ezbounce: irc proxy bnc: irc proxy pdnsd: dns proxy pkspxy: pgp public key server proxy xfwp: X proxy openh323: internet telephony (can be used for proxying) > control framework more suited to gateways than tcpd. xinetd, rlinetd? rinetd? > Because I don't want a caching http proxy with good > performance (though the latter wiould be nice). I want > an Obviously Safe To Run http proxy which supports the > access-control mechanism that I have designed. i don't know if dhttpd, boa, etc. would fulfill the first requirement, but the second is actually a "no, i don't want to use other software" ? If your access-control mechanisms are that good, why don't you ask the others to support them, too? Even if you are going to write one yourself, this could ease migration to your suite. Just my 2¢, and happy hacking. Greetings, Erich
Re: lintian - man pages
> E: redael: binary-without-manpage redael > E: redael: binary-without-manpage redael-filmview > W: redael: file-in-unusual-dir share/man/man1/redael.1 > W: redael: file-in-unusual-dir share/man/man1/redael-filmview.1 try installing the man pages into usr/share/man/man1 > W: redael: package-contains-upstream-install-documentation > usr/share/doc/redael/INSTALL > E: redael: symlink-should-be-relative usr/share/doc/redael/INSTALL > /usr/share/automake/INSTALL > > A generic INSTALL is required by GNU standards, no? i'm using autotools > to build stuff. Should i replace the symlink with a copy of the file? well, as packages are already installed, and INSTALL Document isn't very useful with Debian, is it? Configuration should go into other Documentation files. The E: is about relative symlinks, so your links work withing chroots. Greetings, Erich
Re: Fw: Bug#115631: xmms-jess needs to depend on the current libsdl1.2debian libs
> [for general knowledge] i've looked throught the archives + google and > can't find anything on libsdl1.2debian, could someone please tell me > what the difference is, and why I need to change. Also how long will > libsdl1.2debian be in sid for. read this thread: http://lists.debian.org/debian-devel/2001/debian-devel-200110/msg00353.html this goes into the details why this was changed and what has been changed. Greetings, Erich
Re: gpg sign method per picture
> Passau (Germany). The next dd are in Vienna and Munich. afaik There are lot's of them in Munich so maybe there are even some next to passau... Munich actually isn't very far away from Passau ;) It's less than 200 km, or maybe 2 hours. Did you check with the Passau LUG if there is some debian developer there? So i don't think signing a scanned passport is a good way here. The passport should - if possible - be checked "in real life". So please invest this few time into getting good signatures onto your key. Just take your fingerprint with you when you come to munich and tell us in advance - there are quite some developers here at the universities, it won't be hard to meet some of them. P.e. you could have gone to the Systems and met them there. So if you come to munich, send me an email. ;) Greetings, Erich
Re: howto do task packages ?
> Take contact with the maintainer of tasksel for more information on the > new "task" mechanism and to find a solution. Basically it works like this: The Task information is added on creating the "Packages" file, so Tasks are made _only_ on the Archive. (see overrides file) You can do an old-style Task-Package anyways; like "kde" is. These old-style Task Packages do have a major drawback though: they cannot be installed if not all Packages they depend on are available; on uninstalling any of the installed packages you have to remove the task package as well. I do not know if the policy allows for such meta-packages, but i do think so, as they are really useful. Do have a look at the "harden-*" packages, too, these are the successors of some task-packages as well. (task-harden-* ;) The new Task System basically marks all Packages with the corresponding "Task:" Control field to install; not existant or uninstallable packages won't hurt, and you can remove them independently. Do not expect to get into Tasksel. The Task list in Tasksel is to be kept _very_ minimalistic to allow fast and easy installations. As most users don't know what "ocaml" is, nor will need it, don't expect to get this into tasksel. Greetings, Erich
Re: howto do task packages ?
> Ok, but if a user want to install a task and this task isn't listed by > tasksel, how he can install all task packages? > I really don't want a script that scans all debian package looking for > "Task:" header that match my request ... Task's require that 10% of the user's are interested in installing this combination of packages (or something like that) - that's the new task policy. If it doesn't meet this requirement, it's not a task but a meta package. And tasksel DOES scan the Packages files looking for "Task:" headers that match your request. That is much more fault tolerant than the old way with fixed Dependencies. (for example a user has only CDs 1-5, but the task has a package on the last CD 6; the user then could not install the task due to ONE missing program (and probably a not very important one, on the last CD)) Greetings, Erich
Re: howto do task packages ?
> I'm still in trouble with a minor problem, may I call a meta package > "task-*". > The problem is that "ocaml" package already exists so I can't call the > meta package with the same name, still there is no time to rename > packages and fix all dependencies before tomorrow ... what about meta-ocaml? The Source Package for "kde" is called meta-kde, so i would stick with that. Greetings, Erich
New Python Policy and libming
I'm the maintainer of the libming packages. Libming has Python bindings, so i made a package python2-ming. The Python policy has changed now, and Python 2.1 is now the default python, so i recompiled my package. Could someone with python experience (i havn't used python much; i don't like the indentation enforcing... i'm a perl guy ;) ) please have a look at my new packages, available at http://www.fachschaften.uni-muenchen.de/~erich/debian/ming/ before upload? Furthermore: Should i make a python1.5-ming package? Ming isn't stable yet, so people using ming should be able to use python 2.1... Maybe i'll do a python2.2-ming package instead. The old package was called python2-ming, the new probably should be called python-ming, shouldn't it? python-ming provides python2-ming; do i have to do other things (like requesting the removal of python2-ming from the archive?) Thanks for your help, Greetings, Erich
Re: [SoftwareSuspend-devel] RFS: hibernate
Hi, i'll be sponsoring this upload. Cameron, i'm doing the following changes to your package, please tell me if that is okay so i can upload for you: - rename package to "hibernate-script" to keep it consistent with upstream naming - minor whitespace changes - removed kernel-patch-swsusp suggestion. we don't know if this will ever exist, if it will be named so (and not swsusp2) or if swsusp2 will just be merged into 2.6 - added a "2" to "Software Suspend" in the descriptions first-line. the modified version can be found at people.debian.org/~erich/hibernate-script/ Is the dependency on dash needed? i'd prefer to keep the list of dependencies low. Albeit i do have dash installed myself as default shell, and i consider it being a good choice. I'd suggest adding a "Recommends: dash" and using /bin/sh in the script instead. (dash itself will then suggest making /bin/sh a link to dash) Greetings, Erich Schubert -- erich@(mucl.de|debian.org) -- GPG Key ID: 4B3A135C(o_ To understand recursion you first need to understand recursion. //\ Wo befreundete Wege zusammenlaufen, da sieht die ganze Welt für V_/_ eine Stunde wie eine Heimat aus. --- Herrmann Hesse
Re: [SoftwareSuspend-devel] RFS: hibernate
Ok, i'll wait for 0.99 then and give it a few suspend cycles. Cameron, if you'd like to, feel free to prepare a new package yourself. But i'll check the diff and build it myself before uploading of course. ;-) I agree with the "hibernate" name; i think your "recommends" additions (i think recommends are better for the console-locking thing) are useful and i do prefer using /bin/sh and making dash a mere "suggests" ;-) Greetings, Erich Schubert -- erich@(mucl.de|debian.org) -- GPG Key ID: 4B3A135C(o_ To understand recursion you first need to understand recursion. //\ Wo befreundete Wege zusammenlaufen, da sieht die ganze Welt für V_/_ eine Stunde wie eine Heimat aus. --- Herrmann Hesse
Re: ITA: enigma -- A game where you control a marble with
Hi, I am working in the enigma package update (I am trying to adopt it). I see that this package don't have a VCS. Yes, it doesn't have one yet. Do you think that is a good idea add enigma to salsa? If it is true, could anyone create a salsa repo to commit it and give me access? As suggested, it would make most sense to do this in the larger debian games team project. When looking into bug fixes, it may be desirable to get some fixes from github, and contribute back compile fixes there: https://github.com/Enigma-Game/Enigma Because of fixes, it may be worth following git; there does not appear to be major development happening anymore, all fixes. Please note that it depends on libzipios++, which is orphaned: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=834214 I do not know if enigma can be made working with newer libzipios v2 (which doesn't appear to be packaged anyway). Upstream includes an old copy of zipios 0.x; which is not desirable because of security issues (any bug in zipios then needs to be fixed in enigmas copy, too). Because of this, we have been using a dfsg tarball, with zipios and the "main menu music" removed (see changelog). If I recall correctly, it was not clear what the license of the music was; and as a mod file, it may contain copyrighted samples... Regards, Erich
Re: Tarball question
I've applied a few days ago as debian developer and currently waiting for being assigned an AM ;) so my answer is just my opinion, not based on much experience ;) > 1. I keep up the distinction between the two tarballs. This has > the disadvantage that I have two write two rules files etc. and > yields two orig.tar.gz. Like it was done by the previous maintainer? I consider this a good idea if the two parts might be updated independently; if i understand you correctly, there's also documentation in the first tarball - then i would prefer the following > 2. I merge the two tarballs into one, which contains the > original tarballs in two subdirectories. This would be nice > because I would need only one orig.tar.gz, and would not > increase the total size. did you look at other packages with the same problems etc.? There will surely be some out there. I also like the way xfree builds: the tarball contains the official tarball which will be extracted and patched during the build process. So i think it would be possible that you make a source tarball containing just the two upstream tarballs and a debian/rules file which extracts both tarballs into a working dir, patches them and then starts building the packages. Ths disadvantage is that if somebody wants/needs to compile mozart himself, he'll have to download more data. > 3. I build the documentation from the sources. This requires > Java, and as this is a somewhat tricky dependency, this > solution was given up some time ago. A build-dependency on java (where i do not understand why jdk1.1 could go into non-free...) which isn't inside the debian tree - that would be very ugly and worth a lot to avoid. Did you try building it with other sgml parsers? Greetings, Erich -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: When can I include my package in stable?
Robin schrieb: > What are the conditions for a package to be included in stable? > I have looked through the policy document to find any clues on this but > I couldn't find anything. It's actually quite well described... An existing "stable" will only be changed for security and critical updates. But there will be new "stable" releases (of course). This process, called a "freeze" has just begun (see Mailing List Archives, base is freezing) During the freeze, no new features are to be added to packages, only bugs may be fixed (so hopefully no new bugs arise) After some quality testing, and after all serious bugs have been fixed, "frozen" will be released and become the new "stable". So if your package has no serious bugs (and no package it depends on has serious bugs!), it will surely be in "testing" now. It will then make it into "frozen" and thus "stable" by itself. Greetings, Erich -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: GPG key
> This is an output of: > gpg -v -v -v -v --with-colons --list-keys porridge > > Does anyone understand anything of this mess and can provide me > with some clues on how to read it? I could not find any help in > gnupg documentation. Why use it then? ;) -veryveryveryverbose ;) > (Hint: anything that has "Marcin Owsiany" in it is me, > everything else is not me) the others are signatures. This is a colon-separated table first column is the type (pub = public key, uid= user id, sig =signature second column is "u" for user ids, pub and sub. third column is key-length in bits just compare the values with the regular output to find out their meaning. If your are wondering who the "others" are - that are signatures on the keys. Greetings, Erich -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Needa sponsor/advocate
> Description: Translates text files between Mac, DOS, and Unix formats > 'eol' contains 4 programs that help you deal with cross-platform text > files: >- tounix converts a text file into Unix format (eol=lf) from any format. >- tomac converts a text file into Macintosh format (eol=cr) from any > format. >- todos converts a text file into DOS format (eol=crlf) from any format. >- towin converts a text file into DOS format (eol=crlf) from any format. Do you know "recode"? recode knows over 200 different character sets and file formats and can easily be used for that. So insted of making separate programs, i'd suggest using aliases like alias dos2unix='recode dos/CR-LF..l1' alias unix2dos='recode l1..dos/CR-LF' alias unix2win='recode l1..windows-1250' Recoding isn't trivial, and your claim "from any format" won't hold for sure, as most codeset's cannot be distinguished at all. Furthermore it looks like converting to Mac isn't completely done by replacing the linefeeds with carriage returns. Windows does use a different codepage as dos, afaik! Even DOS doesn't always use the same Codepage. It usually uses 437 OR 850 though. So expect to get bugs over bugs for your package. But i don't want to warp you from becoming a Debian Packager, i'm still in the New Maintainer Process myself. I'm doing Debian Packages for a Library i found in the 'net not available for Debian yet - and learned a lot as it contains wrappers for perl, python, php (and ruby and java, but i couldn't get these to work yet...) - so my source package generates 7 binary packages, i needed to split correctly. Greetings, Erich PGP signature
lintian-warning copyright-lists-upstream-authors-like-dh_make
> W: prips: copyright-lists-upstream-authors-like-dh_make I've run into that warning with my packages, too. Is this really intended? Is it a bad-thing (tm) to fill out the dh_make template? i could not find this rule anymore in the lintian on the mips box i just checked, btw. So maybe this is already removed. Greetings, Erich -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: looking for a sponsor
> Perhaps I've expressed myself a little wrong. Consider me an upstream > developer, rather than a package maintainer. (I've only created a > package since it's a little easier to install than a .tgz. If my > sponsor wants/needs to create a new package from source, that's ok > with me.) So actually you are not looking for a sponsor, but for a debian package maintainer? There might be some on the list eager to find new software to show their skills as Debian Maintainers ;) Debian Sponsorship is for upcoming debian maintainers to get their packages into the archive, while not yet being in the keyring themselves. It's not intended for People to bring their Software into the Debian Archive without being Maintainers themselves. AFAIK ;) I don't know what's the best way to do this. Maybe have someone upload the package and then do a formal "orphan" for the package; so Debian Developers will see this Package orphaned and might consider adopting the package. Greetings, Erich -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: lintian-warning copyright-lists-upstream-authors-like-dh_make
> > You can also run lintian with the -i (or --info) flag to print these > > automatically. > > Or if you are using debuild "debuild -L -i" to see lintian error against > the source (ie: errors in debian/control) Thanks, i was just about to check the debuild manpage for that option ;) Greetings, Erich -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: XMMS Plugins
> - For the source name, you better keep the upstream choise, so call >your SOURCE package (i.e. the source directory for the first dh_make >run) -. Just a question of procedure: What if i wanted to rename a source package? How would i do this? Not that i want to rename my package right now (it's named libming, although upstream name ist "ming" only; but as this IS a library (and a few utils for the sole use by the library) i consider this name better ;) Greetings, Erich -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: gpg sign method per picture
> Passau (Germany). The next dd are in Vienna and Munich. afaik There are lot's of them in Munich so maybe there are even some next to passau... Munich actually isn't very far away from Passau ;) It's less than 200 km, or maybe 2 hours. Did you check with the Passau LUG if there is some debian developer there? So i don't think signing a scanned passport is a good way here. The passport should - if possible - be checked "in real life". So please invest this few time into getting good signatures onto your key. Just take your fingerprint with you when you come to munich and tell us in advance - there are quite some developers here at the universities, it won't be hard to meet some of them. P.e. you could have gone to the Systems and met them there. So if you come to munich, send me an email. ;) Greetings, Erich -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: howto do task packages ?
> Take contact with the maintainer of tasksel for more information on the > new "task" mechanism and to find a solution. Basically it works like this: The Task information is added on creating the "Packages" file, so Tasks are made _only_ on the Archive. (see overrides file) You can do an old-style Task-Package anyways; like "kde" is. These old-style Task Packages do have a major drawback though: they cannot be installed if not all Packages they depend on are available; on uninstalling any of the installed packages you have to remove the task package as well. I do not know if the policy allows for such meta-packages, but i do think so, as they are really useful. Do have a look at the "harden-*" packages, too, these are the successors of some task-packages as well. (task-harden-* ;) The new Task System basically marks all Packages with the corresponding "Task:" Control field to install; not existant or uninstallable packages won't hurt, and you can remove them independently. Do not expect to get into Tasksel. The Task list in Tasksel is to be kept _very_ minimalistic to allow fast and easy installations. As most users don't know what "ocaml" is, nor will need it, don't expect to get this into tasksel. Greetings, Erich -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: howto do task packages ?
> Ok, but if a user want to install a task and this task isn't listed by > tasksel, how he can install all task packages? > I really don't want a script that scans all debian package looking for > "Task:" header that match my request ... Task's require that 10% of the user's are interested in installing this combination of packages (or something like that) - that's the new task policy. If it doesn't meet this requirement, it's not a task but a meta package. And tasksel DOES scan the Packages files looking for "Task:" headers that match your request. That is much more fault tolerant than the old way with fixed Dependencies. (for example a user has only CDs 1-5, but the task has a package on the last CD 6; the user then could not install the task due to ONE missing program (and probably a not very important one, on the last CD)) Greetings, Erich -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: howto do task packages ?
> I'm still in trouble with a minor problem, may I call a meta package > "task-*". > The problem is that "ocaml" package already exists so I can't call the > meta package with the same name, still there is no time to rename > packages and fix all dependencies before tomorrow ... what about meta-ocaml? The Source Package for "kde" is called meta-kde, so i would stick with that. Greetings, Erich -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
New Python Policy and libming
I'm the maintainer of the libming packages. Libming has Python bindings, so i made a package python2-ming. The Python policy has changed now, and Python 2.1 is now the default python, so i recompiled my package. Could someone with python experience (i havn't used python much; i don't like the indentation enforcing... i'm a perl guy ;) ) please have a look at my new packages, available at http://www.fachschaften.uni-muenchen.de/~erich/debian/ming/ before upload? Furthermore: Should i make a python1.5-ming package? Ming isn't stable yet, so people using ming should be able to use python 2.1... Maybe i'll do a python2.2-ming package instead. The old package was called python2-ming, the new probably should be called python-ming, shouldn't it? python-ming provides python2-ming; do i have to do other things (like requesting the removal of python2-ming from the archive?) Thanks for your help, Greetings, Erich -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Renaming binary packages + Python
I'm the maintainer of the libming packages. Libming has Python bindings, so i made a package python2-ming. The Python policy has changed now, and Python 2.1 is now the default python, so it might be good to rename my package to python-ming? This is a binary package, the source package remains libming. if so, what do i have to do for that? upload, then file a bug against ftp.debian.org to remove them? Is anybody familar with the new python? I've never used python, i'm just packagin the python-bindings! Please have a look at my new packages, available at http://www.fachschaften.uni-muenchen.de/~erich/debian/ming/ before upload? Furthermore: Should i make a python1.5-ming package? Ming isn't stable yet, so people using ming should be able to use python 2.1... Maybe i'll do a python2.2-ming package instead. Thanks for your help, Greetings, Erich -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: building a sponsored package
> I think that's Maintainer: in the control file (and the .dsc). It makes > sense to me that the maintainer of a .dsc is the person primarily > responsible for the package, while the maintainer of a .changes is the > person responsible for uploading this particular build. This also The Maintainer schould always be the same, i think. Either someone maintains a package or he doesn't. > matches the fact that porters typically upload with their name in the > .changes Maintainer: field. Because they upload with the Architecture limited to what they uploaded. They are somehow the maintainer of the package for that specific architecture. for example Non-Maintainer-Uploads: the Maintainer shouldn't change - but the Changed-By: field has to get the Name of the Person doing the NMU. So i think that's straightforward. The Maintainer is "responsible" for the package, the Changed-by: responsible for his changes. More specific is the Maintainer the Contact for Requests about that package. And this is NOT the sponsor. Bugs should be adressed by the sponsored new maintainer themselves. Sponsors just review the maintainers work and do the upload. Greetings, Erich -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Testing update-Excuses
> http://ftp-master.debian.org/testing/update_excuses.html.gz> says: One question to reading that page: "libming" is a "valid candidate" and is depending on libc6 only. The dependency is versioned on (>= 2.2.3-7), but libc6 2.2.4-1 is in testing. Any idea what is keeping libming out of testing? Is it php4 missing for ia64 and arm which is keeping the whole libming out of testing? Which is then held back by libtool 1.4 which is considered buggy? http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=66135&repeatmerged=yes That would be ugly that the whole lib cannot enter testing, because of the php4 part. :-( Greetings, Erich -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: How granular should a package{,set} be?
Well, i think the basic principle is "split everything that people might want to install independantly or that can be upgraded independantly" So i think it's a good idea to enable people to install most parts of your suite, but leave the httpd away (if they want to use some other httpd etc.) I don't think the -docs package should Recommend any non-docs package. Many people will install your kit on one machine, the docs on another. But p.e. it makes sense that libgnome-doc recommends libgtk-doc FYI: The first thing that came into my mind, when i read about your package, was "oh, another proxy" and "is that really really secure". It scares me a bit that you include even an httpd server (which have to do a lot of security checks)... Why not use existing, audited software? There are small httpd servers, what's wrong with them? Same for the httpd proxy: If i look at squid, a proper caching httpd proxy with good performance is a LOT of work, why not use squid? And if squid is lacking some features etc. create a spin-off project from squid with a few "squid-veterans" which have learned from their mistakes with squid. Same for all other parts of your software. Just the 2¢ that came into my mind, i haven't looked at your code at all, these are just prejudices to any new software having more parts than developers. Greetings, Erich P.S. There is no pseudo package httpd or web-server provided by apache? We've got quite a few httpd's (roxen, boa, dhttpd wn) so maybe two web-server and web-server-cgi pseudo packages would be a good idea? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: How granular should a package{,set} be?
> The "upgraded independantly" is a good point. As an > in-development package, I wouldn't at the point be > entirely happy with people running older versions if > they wanted stability. You can use versioned Depends for that, if that is necessary. If not necessary, don't do this. But during heavy development, versioned depends are ok (if you don't know yet that they play together well) But don't expect people to run different versions ;) expect them to upgrade every day, because lot's of debian unstable users do have the "upgraditis" virus ;) What i meant is p.e. splitting of data from program code. So a game putting the sound data files, graphics, levels and binaries into separate packages can be very useful: people will (might) have to download the binary and level packages only for an upgrade. or someone might do a "other levels" package, providing a different level set for the same game. --[ so back to off-topic ]-- i don't want to stop you from doing this. Good additional proxies would be great. But better do one proxy right than 10 proxies insecure. That's what scares me most: you want to do everything. Next you want to do traffic shaping as well (which is a pain in the ass, even with the tc tool, but even more by doing rtnetlink yourself... but the possibilites are great...) next step is then writing the tcp stack yourself. In Security, it is most important to have secure and reliable features, quantity is much less important than quality. But remember: don't let me discourage you. Especially this discussion is independant of the Debian packages, i'm not even yet a maintainer myself. > "another proxy"? Please point me to a decent, non-abandoned, > Free software proxy firewall kit. I know only of Zorp, and "Proxy Suite" from SuSE? I think they have released only ftp yet, though... and the homepage disappeared during the redesign :-( Than i've seen the "falcon firewall project" there might be even more. "Astaro Security Linux" is a linux distribution with your goals i think. Ok, none of them is as complete (or aims to be, i think) as yours. > As to the security aspects, I'd much rather you didn't make > such implications without at least having a look for yourself. i'm just afraid of security holes; but that's why i stated this was just what came into my mind first: i wanted to state that i didn't do so. > One of my design goals is that it be possible to audit the kit > merely by reading the source through once. The code isn't that does sound great ;) > Please point me towards an existing, audited, maintained, > free software ftp gateway. Or a nice, unified, access- Just to give a few existing, mostly maintained and quite some audited proxy servers for differen protocols: ftp-proxy: ftp proxy server from SuSE jftpgw: ftp proxy / gateway perdition: pop3 and imap4 proxy server oops: http caching proxy server squid: http caching proxy server tinyproxy: http proxy server muffin: personal http proxy (like rabbit, wwwoffle, filterproxy, junkbuster) socks4-server: socks server tsocks: transparent socks proxy dante: socks server smtpd: mail proxy for firewalls plum: irc proxy madoka: irc proxy dircproxy: irc proxy ezbounce: irc proxy bnc: irc proxy pdnsd: dns proxy pkspxy: pgp public key server proxy xfwp: X proxy openh323: internet telephony (can be used for proxying) > control framework more suited to gateways than tcpd. xinetd, rlinetd? rinetd? > Because I don't want a caching http proxy with good > performance (though the latter wiould be nice). I want > an Obviously Safe To Run http proxy which supports the > access-control mechanism that I have designed. i don't know if dhttpd, boa, etc. would fulfill the first requirement, but the second is actually a "no, i don't want to use other software" ? If your access-control mechanisms are that good, why don't you ask the others to support them, too? Even if you are going to write one yourself, this could ease migration to your suite. Just my 2¢, and happy hacking. Greetings, Erich -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: lintian - man pages
> E: redael: binary-without-manpage redael > E: redael: binary-without-manpage redael-filmview > W: redael: file-in-unusual-dir share/man/man1/redael.1 > W: redael: file-in-unusual-dir share/man/man1/redael-filmview.1 try installing the man pages into usr/share/man/man1 > W: redael: package-contains-upstream-install-documentation >usr/share/doc/redael/INSTALL > E: redael: symlink-should-be-relative usr/share/doc/redael/INSTALL >/usr/share/automake/INSTALL > > A generic INSTALL is required by GNU standards, no? i'm using autotools > to build stuff. Should i replace the symlink with a copy of the file? well, as packages are already installed, and INSTALL Document isn't very useful with Debian, is it? Configuration should go into other Documentation files. The E: is about relative symlinks, so your links work withing chroots. Greetings, Erich -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Fw: Bug#115631: xmms-jess needs to depend on the current libsdl1.2debian libs
> [for general knowledge] i've looked throught the archives + google and > can't find anything on libsdl1.2debian, could someone please tell me > what the difference is, and why I need to change. Also how long will > libsdl1.2debian be in sid for. read this thread: http://lists.debian.org/debian-devel/2001/debian-devel-200110/msg00353.html this goes into the details why this was changed and what has been changed. Greetings, Erich -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Renaming binary packages + Python
I'm the maintainer of the libming packages. Libming has Python bindings, so i made a package python2-ming. The Python policy has changed now, and Python 2.1 is now the default python, so it might be good to rename my package to python-ming? This is a binary package, the source package remains libming. if so, what do i have to do for that? upload, then file a bug against ftp.debian.org to remove them? Is anybody familar with the new python? I've never used python, i'm just packagin the python-bindings! Please have a look at my new packages, available at http://www.fachschaften.uni-muenchen.de/~erich/debian/ming/ before upload? Furthermore: Should i make a python1.5-ming package? Ming isn't stable yet, so people using ming should be able to use python 2.1... Maybe i'll do a python2.2-ming package instead. Thanks for your help, Greetings, Erich
Re: [SoftwareSuspend-devel] RFS: hibernate
Hi, i'll be sponsoring this upload. Cameron, i'm doing the following changes to your package, please tell me if that is okay so i can upload for you: - rename package to "hibernate-script" to keep it consistent with upstream naming - minor whitespace changes - removed kernel-patch-swsusp suggestion. we don't know if this will ever exist, if it will be named so (and not swsusp2) or if swsusp2 will just be merged into 2.6 - added a "2" to "Software Suspend" in the descriptions first-line. the modified version can be found at people.debian.org/~erich/hibernate-script/ Is the dependency on dash needed? i'd prefer to keep the list of dependencies low. Albeit i do have dash installed myself as default shell, and i consider it being a good choice. I'd suggest adding a "Recommends: dash" and using /bin/sh in the script instead. (dash itself will then suggest making /bin/sh a link to dash) Greetings, Erich Schubert -- erich@(mucl.de|debian.org) -- GPG Key ID: 4B3A135C(o_ To understand recursion you first need to understand recursion. //\ Wo befreundete Wege zusammenlaufen, da sieht die ganze Welt für V_/_ eine Stunde wie eine Heimat aus. --- Herrmann Hesse
Re: [SoftwareSuspend-devel] RFS: hibernate
Ok, i'll wait for 0.99 then and give it a few suspend cycles. Cameron, if you'd like to, feel free to prepare a new package yourself. But i'll check the diff and build it myself before uploading of course. ;-) I agree with the "hibernate" name; i think your "recommends" additions (i think recommends are better for the console-locking thing) are useful and i do prefer using /bin/sh and making dash a mere "suggests" ;-) Greetings, Erich Schubert -- erich@(mucl.de|debian.org) -- GPG Key ID: 4B3A135C(o_ To understand recursion you first need to understand recursion. //\ Wo befreundete Wege zusammenlaufen, da sieht die ganze Welt für V_/_ eine Stunde wie eine Heimat aus. --- Herrmann Hesse
