Re: How can a non-DD fix broken packages?
On Tue, 30 May 2006, Steve Langasek wrote: > The difference being that most of the time when someone "sponsors" an NMU, > they're effectively shirking their own duty to follow up on the package and > ensure that the NMU hasn't introduced any regressions. Often, they're > shirking their duty to even check the correctness of the provided patch > themselves. IMHO we really should have a global NMU blacklist (no, never per-package. That way lies lameness) which we could ask the ctte to place maintainers in for a few months when someone does the NMU-and-forget routine and that NMU causes problems: screw up an NMU and don't clean up after yourself, get punished by not being able to screw up through NMUs again for a while. We should *also* have the pts auto-add anyone who does an NMU to receive all bug reports. If you NMU, you *are* responsible for it, and it is not nice to make it so easy for one to forget he NMUed something, after all. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: SASL2 (Bug#368370)
On Wed, 24 May 2006, Wolfgang Lonien wrote: > wow, pretty bad news in this week's DWN about cyrus-sasl2 being > orphaned. I checked popcon, and it has some 12.000 installations, so: Yes, and it is one of the hariest, most horrible packages to maintain I know of. > I'd really like to do something about it, but I doubt I could, at least > not alone. I never took over a package, and hardly know how to apply > patches correctly. There is an alioth team to take care of cyrus-sasl2. It is not managing to do much (because nobody there seems to be in the mood/have the free time to tangle with it right now). But that team has several DDs, so you get expedited sponsoring if you join it and do sasl fixes there. > So my point is: would anyone give me a good intro or even consider > co-maintainership, so I could learn all that stuff? Seems like for > people like me, we need some kind of Debian school ;-) You are welcome to the team, join the mailing list, and send us your alioth ID to be added to the project. The team did not adopt the package because it did not manage a single upload yet, I think :-) -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Native package or not?
On Sun, 12 Feb 2006, Manoj Srivastava wrote: > This is interesting. When I remove a file completely from > ./debian, as I do in the case of fvwm, diff says "ignoring deletion > of files ...". So, if I had instead just truncaterd the file, it > would be removed from the unpacked tree, while remaining as a zero > byte file in my SCM, but removing it from my SCM means it remains in > the tree after dpkg-source -x. > > ironic, I think. And higly useful. I use that feature all the time (along with some rm -f in debian/rules clean) to ship less crap in the diff file. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Re-libtooling + automake
On Fri, 03 Feb 2006, Bas Wijnen wrote: > On re-reading this message, it seems to have a harsh tone. Sorry about that, > that was not my intention. Also I don't want to start a flame-war or > anything, but I do want either me or "the others" (whoever that includes) Ah, no I didn't take that as harsh, and no flame-wars will come from me :) > Apart from these points, which I hope we now all agree on (although I fear > this isn't the case), there are some other things: I actually agree with all of them. > - The .diff.gz becomes readable (a big advantage IMO, I usually check the diff > before sending a package to my sponsor, to see if I didn't accidentily put > things in that don't belong there). I am so used to skipping noise in diff.gz, I don't even care. Its sort of a trade-off. Either clean diff.gz, or more autobuild time. I don't care either way, but I *do* have packages that take LONG times to bootstrap (because they use autotrace, etc), so I engineered my workflow to do it at VC export time. > - It is impossible to accidentily forget to rerun the autotools. My own workflow makes that impossible to happen. I always build directly from VC, and no autogenerated file survives inside my VC repositories. So, that means I get a fresh copy *without* any autotools stuff, which *requires* bootstrapping to work. And debian/rules notices that, and calls the bootstrapping script. OTOH, people NMUing or messing with the package without reading the rules file first might get screwed, since one is required to AM_MAINTAINER_MODE (or to play the touch game) when not bootstrapping at build time. > And the only bad thing about it seems to be resource consumption on the > buildds. Compiling will cost more time, and the build-depends need to be AND on the local development machine, unless special measures are taken. But yes, that's about the only downside: autotools are slow as heck to bootstrap. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Re-libtooling + automake
On Thu, 02 Feb 2006, Damyan Ivanov wrote: > Bas Wijnen wrote: > > And I may be becoming repetitive, but I still haven't heard any reason why > > running autoconf/automake from debian/rules would be bad. Obviously you > > need > > to depend on the correct version and explicitly call it (Depends: > > automake1.9 > > ; export AUTOMAKE=automake-1.9), but I don't see a problem in that either. > > > > Many problems solve themselves when you compile from source instead of using > > pre-built files. That is true for executables, it is true for Makefile.in > > and > > configure as well. > > QA team seem to disagree. > See http://sam.zoy.org/lectures/20050910-debian/img0.html Watch it! That reply is very prone to being misunderstood. You are STRONGLY urged to re-bootstrap autotools, both I (the autotools-dev maintainer) and the writer of the above slides (which are damn nice, thanks for pointing them out!) *agree* with that. The slides urge one to bootstrap _before_ shipping the debian package, instead of doing it at package build time. Which, I should add, is exactly what I also consider to be the best option, and the way I do it on all my packages. So, yes, *do* build everything from source (i.e. bootstrap all autotools from known-good Debian packaged autotools). You just don't need to do it at dpkg-buildpackage time, you can also do it before that. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: files for an initscript that is run before mountall.sh
On Mon, 30 Jan 2006, Jonas Meurer wrote:
> now my question is, where should i place the check scripts instead?
> is /lib/cryptsetup/{pre,post}check correct?
Yes.
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: How to close Bugs in experimental
On Wed, 18 Jan 2006, Henrique de Moraes Holschuh wrote: > On Wed, 18 Jan 2006, Thijs Kinkhorst wrote: > > There's currently no other way to specify a fixed-version other than > > mailing '-done' or using 'close. Mailing -done is not always > > Refer to the "found" and "notfound" commands in the BTS reference. > "notfound" seems to do what you want, to me. Or maybe I didn't understand > your problem correctly. Sorry about that, you're correct, you need to use the close command, or the -done@ address currently. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: How to close Bugs in experimental
On Wed, 18 Jan 2006, Steve Langasek wrote: > > AFAIK, [EMAIL PROTECTED] should be used for unstable uploads (it already > > is, I > > think), and notfound commands to [EMAIL PROTECTED] should be used instead of > > fixed-in-experimental tags. > > Wrong. notfound commands don't do anything that's at all useful here. You Drat, I just re-read the definition of notfound, and you're right, it is useless for fixed-in-experimental. I was under the impression that it would work because of some testing I did a while back, it is now obvious that I probably screwed up on that testing (or I am not recalling some details correctly). > need close or -done (and yes, katie would implement this using -done, just > as it already does for maintainer uploads to unstable). If the BTS will cope well with -done and not close the bug completely, using -done (or de-deprecating -close) would be best, yes. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: How to close Bugs in experimental
On Wed, 18 Jan 2006, Thijs Kinkhorst wrote: > There's currently no other way to specify a fixed-version other than > mailing '-done' or using 'close. Mailing -done is not always Refer to the "found" and "notfound" commands in the BTS reference. "notfound" seems to do what you want, to me. Or maybe I didn't understand your problem correctly. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: How to close Bugs in experimental
On Wed, 18 Jan 2006, Frank Küster wrote: > Henrique de Moraes Holschuh <[EMAIL PROTECTED]> wrote: > > No, as close commands ARE clearly deprecated as well, and not at all > > equivalent to adding a tag. We are taliking about uploads to experimental, > > after all. > > > > AFAIK, [EMAIL PROTECTED] should be used for unstable uploads (it already > > is, I > > think), and notfound commands to [EMAIL PROTECTED] should be used instead of > > fixed-in-experimental tags. > > Why not use bug#-done with an appropriate Version pseudoheader, also > for uploads to experimental? I believe that closes the bug. The BTS seems to differentiate open bugs to bugs which are not found in any versions anymore. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: How to close Bugs in experimental
On Wed, 18 Jan 2006, Steve Langasek wrote: > On Wed, Jan 18, 2006 at 09:29:35AM -0200, Henrique de Moraes Holschuh wrote: > > On Wed, 18 Jan 2006, Thijs Kinkhorst wrote: > > > In a more general sense, it's important to note that the > > > fixed-in-experimental tag is deprecated, and definately not necessary > > > It is kinda hard to consider it deprecated while DAK still sets it instead > > of doing a proper job of issuing "notfound" commands to the BTS. > > You mean "close" commands... No, as close commands ARE clearly deprecated as well, and not at all equivalent to adding a tag. We are taliking about uploads to experimental, after all. AFAIK, [EMAIL PROTECTED] should be used for unstable uploads (it already is, I think), and notfound commands to [EMAIL PROTECTED] should be used instead of fixed-in-experimental tags. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: How to close Bugs in experimental
On Wed, 18 Jan 2006, Thijs Kinkhorst wrote: > In a more general sense, it's important to note that the > fixed-in-experimental tag is deprecated, and definately not necessary It is kinda hard to consider it deprecated while DAK still sets it instead of doing a proper job of issuing "notfound" commands to the BTS. I sure hope changing this is in the pipeline of DAK changes, though. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: knmap -- Kde interface to nmap [uploaded]
On Sat, 14 Jan 2006, Russ Allbery wrote: > The problem is, in a nutshell, this doesn't actually work reliably. If It does inside Debian (you can explicitly choose a given version, and upgrade to the next only after some testing). It *mostly* does among minor versions of the autotools, if whomever wrote the scripts didn't abuse internals or fork-and-modify macros. > the Autoconf tools had a clean language specification that they continued > to implement or at least only changed at major revisions, you could be Now, that's a valid complain. But it is a reason to use something ELSE than autotools, and not to keep around old broken stuff inside Debian packages. > Unfortunately, in practice, interfaces go away or change radically in > minor releases, people have to use locally hacked versions of the tools to > work around bugs (heck, Debian's are even modified to fix major bugs that > upstream hasn't fixed), and it's a random lottery whether the next And *THAT* is the reason why you should autoreconf (as in regenerate everything autotools, and that includes libtool) often, using the Debian packages. Now, why the GNU people taking care of auto* can't get version numbering right, I have no idea. autoconf should have been versioned 3.00 instead of 2.50, and automake 1.5 should have been automake 2.0. But I haven't seen great changes since automake 1.6, nor since autoconf 2.52. They now warn you of breakage the previous versions didn't complain about, but that's something gcc 4 does as well, for example. Maybe I am just lukcy? > You're probably safe doing this with small packages, but I cringe at the > idea of re-running the autotools automatically on a substantial package. Well, it depends. I *rewrote* the autotools scripts for substantial packages to clean up the usual load of crap people put in there, because I know well that it won't stand up for abuse (crap and dumb hacks are something that lacks good resilience, as we all know :P). This speaks against the quality of the autotools documentation and its learning curve. I always rebuild the entire auto chain before every upload of every one of my auto-* packages. As long as I fix anything hackish or plain broken done by upstream as soon as it shows up in my diffs, it is quite rare for me to have to revisit any given section of an .am or .ac file. Of course, I am not maintaining anything that *forked* the autotools macros and expected to get away with it by never merging back changes from upstream as autotools evolved. People stuck with that legacy will, of course, go through a lot of pain, regardless of which reasons caused the fork in the first place. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: knmap -- Kde interface to nmap [uploaded]
On Sat, 14 Jan 2006, Bas Wijnen wrote: > Of course I know the classical argument against this: To build a program, you > should only need to do "./configure;make;make install". configure is the > platform independant script, autoconf should only be used by upstream. Well, that's an stupid argument alright. We are talking about *debian packages*, not about building programs. To build a Debian package, you install the build dependencies, and issue an dpkg-buildpackage. That said, people who just "./configure;make;make install" without even reading the f* docs first deserve whatever they get out of it, and that includes broken crap as much as working goodness. But if this person is working on a Debian package, he will be inflicting the results on a lot of people. > The user who only downloads the tarball needs to do nothing more than > "./configure;make;make install". > But running > "./autogen.sh;make;make install" It usually goes ./autogen.sh; configure ; make; make install > autoreconf has the annoying property of preferring automake 1.4 if it is > installed. So you need to set the environment to the proper versions for it Automake 1.4 should never be installed in any system where most stuff uses non-ancient-burried-and-dead automake versions :-) build-conflicting with it is always justified IMHO. > to work. I prefer directly calling the correct version of it. autoreconf lets you explicitly specify what programs to call, see the manpage... "The environment variables AUTOCONF, AUTOHEADER, AUTOMAKE, ACLOCAL, AUTOPOINT, LIBTOOLIZE are honored." -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: knmap -- Kde interface to nmap [uploaded]
On Fri, 13 Jan 2006, Steve Langasek wrote: > There are *always* libraries in a state of transition in Debian. Using the > Debian libtool means limiting those transitions to packages which have a > valid reason for depending on the transitioning library, instead of giving > us transitions that ripple through all the indirect reverse-dependencies. > > Just to be clear, relibtoolizing should only need to be a one-time thing. We differ in opinions, here. I'd rather people wrote a proper autogen.sh-like script for their packages, so that they could easily and PAinlessly autoreconf (or the equivalent) their packages often. For most up-to-date packages re. autotools, this is just a call to autoreconf. The reason is that bugs in libtool propagate to packages until they re-libtoolize... an one-time thing is better than nothing, it gets a much better than average version of libtool (Debian's current one in sid) into the package. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: relibtoolizing when necessary (was: RFS: knmap -- Kde interface to nmap [uploaded])
On Fri, 13 Jan 2006, Florian Ernst wrote: > > I thought I understood at least the reason to include diffs for a > > config.guess and config.sub. But IMHO relibtooling is only needed when > > certain libraries are in a state of transitions. Could you (or Florian (or You should always relibtoolize. The only exception are for packages for which upstream uses Debian libtool from sid. Debian libtool does many things that are much saner for Debian than up-to-date upstream libtool. And non-up-to-date libtool from anywhere is always a Bad Idea. > Of course, maintainers shouldn't relibtoolize just for the sake of it, > but sometimes it's truly worth the effort. Unless the package already uses Debian libtool from upstream, it ain't "for the sake of it..." -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Proposal for collaborative maintenance of packages
On Tue, 20 Dec 2005, Russ Allbery wrote: > You just lost the people that I'm talking about. I can explain a > changeset, but merges are deep black magic that are extremely difficult to > understand except at a highly abstract level, and when using a distributed > VCS, they have to deal with merges all the time. Well, these are not people I would give write access to a repository for doing Debian packaging work, then. Note that contributions in the form of patches or of another sort (can we say "we always need better documentation" out loud? :-) ) is always very welcome, so they would not be left out if they really want to help. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Proposal for collaborative maintenance of packages
On Tue, 20 Dec 2005, J. Bruce Fields wrote: > On Tue, Dec 20, 2005 at 03:32:42PM -0200, Henrique de Moraes Holschuh wrote: > > On Tue, 20 Dec 2005, J. Bruce Fields wrote: > > > On Tue, Dec 20, 2005 at 08:47:44AM -0200, Henrique de Moraes Holschuh > > > wrote: > > > > Since bzr (and other arch derivates) have the benefit of NEVER forgeting > > > > which changesets are in a tree, I prefer them over any other distributed > > > > system. If anyone knows of other distributed system that saw the light > > > > and > > > > implemented this, please let me know. > > > > > > What's an example of a VCS that does forget changesets? I'm not sure I > > > understand the requirement. > > > > I never said it was a requirement. > > > > Examples are: all VCSes that do not track every changeset by an unique > > identifier which is not changed even when the changeset is migrated across > > repositories, and all VCSes that lose track of component changesets across > > merges. > > Have you looked at mercurial or git? I think they both do that. > Monotone too, I assume. Yes, they do, I just checked it. Thanks! git is not a VC, though, but it has its uses. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Proposal for collaborative maintenance of packages
Hi J.! On Tue, 20 Dec 2005, J. Bruce Fields wrote: > On Tue, Dec 20, 2005 at 08:47:44AM -0200, Henrique de Moraes Holschuh wrote: > > Since bzr (and other arch derivates) have the benefit of NEVER forgeting > > which changesets are in a tree, I prefer them over any other distributed > > system. If anyone knows of other distributed system that saw the light and > > implemented this, please let me know. > > What's an example of a VCS that does forget changesets? I'm not sure I > understand the requirement. I never said it was a requirement. Examples are: all VCSes that do not track every changeset by an unique identifier which is not changed even when the changeset is migrated across repositories, and all VCSes that lose track of component changesets across merges. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Proposal for collaborative maintenance of packages
On Mon, 19 Dec 2005, Russ Allbery wrote: > Ben Finney <[EMAIL PROTECTED]> writes: > > In other words, a distributed VCS allows all parties to manage their own > > repositories equally, and the project can nominate one of them the > > "official" central repository, without impacting everyone's ability to > > communicate changes between other repositories. > > This may not be the most popular opinion, particularly among fans of > distributed VCSes (and I do understand the merits), but wrapping your mind > around the distributed model isn't easy. I can explain to sysadmins who > have never used a VCS before but who have compiled software and can work > on Debian packages how to use Subversion, but explaining bzr feels rather > intimidating. " You have a central entity, be it a person (the project leader for example) or a bot, which has write access to the main repository. Everyone sends commits (working changesets) to this person/bot, for them to get merged to the main repository. Everyone has a local read-only copy of the main repository that they can use even while offline (which they sync to the main repository every now and then). Everyone has a local read-write repository that they use for ongoing work, even while offline. It is this work that, when deemed ready, is sent as a changeset for inclusion in the main repository. " What IS difficult about it? It is exactly how the Linux kernel is managed, only they have various layers of "project leaders" and no bots. Nobody in the system administrator, development or operation areas where I work would have too much difficulty grasping the basic idea, and it wouldn't take much time to explain the specifics (repository mirrors, etc). Whatever the issues of svn versus bzr are, difficulty of grasping the bzr way of doing things shouldn't be one of them. Since bzr (and other arch derivates) have the benefit of NEVER forgeting which changesets are in a tree, I prefer them over any other distributed system. If anyone knows of other distributed system that saw the light and implemented this, please let me know. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Proposal for collaborative maintenance of packages
On Mon, 19 Dec 2005, Stefan Potyra wrote: > I'd object to this, since one of the goals would be to make it easy to review > packages. So basically you'd need exactly one central place, where the > current version of a sourcepackage can be found, and can be reviewed. However > I'm not quite sure if/how this could be handled with a distributed VCS like > bzr. It works just like it is done for the Linux kernel: people send ready changesets either to a maintainer (through a mailing list pehaps, so that changesets are not lost) or to a bot, which commits them to the master bzr repository. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Creating a randomized cron entry
On Thu, 15 Dec 2005, Don Armstrong wrote: > Why not just something like: > > 0 0 * * * at now + $(( $RANDOM \% 1440 )) minutes [...] Because "at" is something you should never have installed (it is the very first thing I purge, after fixing the dumb wide-open defaults we use for hosts.allow and hosts.deny). "at" has a very bad history security-wise, and I really doubt anyone is seriously maintaining and fixing that thing. Now, if someone would rewrite from scratch an "at" designed and implemented for security, that would be very cool indeed. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Going nuts over debconf
On Sat, 05 Nov 2005, Cameron Patrick wrote: > Henrique de Moraes Holschuh wrote: > > And the proper fix is to call db_stop AND of course fix the daemon to close > > open fds it doesn't need. Unfortunately, there are only kludgy ways to do > > so as the kernel won't tell you which FDs you have that are open. > > That's not quite true. On Linux you can walk /dev/fd/ or > /proc/self/fd/ to find out what FDs are open (and also what files they Ah, had forgotten about this. You're correct. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Going nuts over debconf
On Thu, 03 Nov 2005, Steve Langasek wrote: > On Thu, Nov 03, 2005 at 10:32:07PM -0500, Peter S Galbraith wrote: > > Problem summary: Using debconf and rc.d script hangs package installation > > > I am merging packages `powstatd' and `powstad-crypt' into a single new > > `powstatd' package with encryption enabled. I wrote a debconf script > > that displays a warning in certain cases when the configuration file must > > be edited for the new package to continue working. > > > Upgrading to the new package works fine if the postinst script does not > > start an rc.d process (e.g. because the package conffile doesn't enable > > it). Upgrading hangs when the postinst process is started. > > This normally indicates that the process being started from the init script > doesn't daemonize properly, and still has file descriptors open to debconf. > The standard workaround for this is to call db_stop at the end of your > postinst to force-detach the debconf daemon. And the proper fix is to call db_stop AND of course fix the daemon to close open fds it doesn't need. Unfortunately, there are only kludgy ways to do so as the kernel won't tell you which FDs you have that are open. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: double-shlibs
On Tue, 01 Nov 2005, Nathanael Nerode wrote: > Frank Lichtenheld wrote: > > On Tue, Nov 01, 2005 at 11:21:41AM -0400, -.JavaManiac.- wrote: > >> I have the next linda-warning : > >> > >> W: libefltk2.0-dev; Shared object /usr/bin/ecalc is linked with > >> version 6 and 5of libstdc++. > > > > I can't tell of course if you're suffering from a similar problem or > > if it is right in your case. Essentially, if you compile packages > > in a chroot and your system differs from this chroot, the linda warning > > will often be bogus. > Yes. Go into an unstable chroot and install the package, then run linda > there. And if linda warns you of such issues INSIDE the chroot, do NOT upload the package. It means you cannot currently compile it sanely, so don't do it. You will have to get fixed libraries uploaded to sid first. And never, EVER override this warning. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: gcc best practices | problems
On Sat, 29 Oct 2005, Steve Langasek wrote: > On Sat, Oct 29, 2005 at 09:12:27AM -0200, Henrique de Moraes Holschuh wrote: > > On Sat, 29 Oct 2005, skaller wrote: > > > compiler ABI changes (I believe that doesn't apply here since > > > gcc 4.x uses same C ABI as gcc 3.4, not sure about C++ though) > > > There is a fatal C++ ABI change from 3.4 to 4.0. > > The ABI change is between 3.3 and 3.4, not 3.4 and 4.0. I see. So recompiling would not be necessary, then. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: gcc best practices | problems
On Sat, 29 Oct 2005, skaller wrote: > compiler ABI changes (I believe that doesn't apply here since > gcc 4.x uses same C ABI as gcc 3.4, not sure about C++ though) There is a fatal C++ ABI change from 3.4 to 4.0. All C++ code in Debian has to be updated to compile with 4.0 now (if it uses libraries), or it will be eventually be purged from the archive. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: gcc best practices | problems
On Sat, 29 Oct 2005, -.JavaManiac.- wrote: > if i have a package that doesn't compile against gcc-4.0,what are my > choices??and what is the best ??,Build-Depends on gcc-3.4 or modify > the sourcecode to make it clean to gcc-4.0??. Make it clean for gcc-4.0. Code that does not work with gcc 4.0 belong in two classes: 1. Illegal/broken/incorrect C constructs 2. gcc 4.0 bugs. Almost all ocourrences of (2) have been fixed already, so you can safely go with (1) unless you do know better. And (1) are bugs, and bugs should be fixed. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: handling of duplicate bts entries
On Fri, 21 Oct 2005, Jean-Marc Ranger wrote: > What's the correct way to handle duplicate entres in bugs.debian.org ? > Merge ? Personal feeling would be to close one immediately while > providing a link somehow. Just merge them. It doesn't matter if the duplicates are caused by a MTA snafu, or two people complaining about the same thing :-) -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: sysinfo upstream tarball problems
On Mon, 17 Oct 2005, Simon Richter wrote: > Both solutions are correct, modifying the Makefile is easier to > understand for someone else looking at the package and will also show a Modifying an *automake* generated makefile and "easier to understand" do not belong in the same sentence. Fixing the Makefile.am file and rerunning automake (preferably the latest one to get rid of bugs) is much easier on the brain. That doesn't mean you have to run it on the build, you can run it before uploading (but you better have automated methods that guarantee you won't forget to). -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Putting accented characters in manpages?
On Thu, 06 Oct 2005, Norbert Preining wrote: > Well if the Name of the author contains latin1 characters, I would > suggest to include the letters. Otherwise it is just plain wrong. You don't have that option. Transliterate it just like our poor CJK friends have been forced to do for a LONG time now. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Putting accented characters in manpages?
On Thu, 06 Oct 2005, Rogério Brito wrote: > So, I guess that's not only me that would benefit from some light from > people from debian-mentors on what is the best-current-practice on > getting accented characters on manpages. Basically, until UTF8 support is fully deployed for manpages (it isn't right now AFAIK), you have to refrain from using non-ASCII. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh
Re: diff.gz contains more than just debian directory
On Thu, 22 Sep 2005, Vedran Fura? wrote: > Is it OK to have more than debian directory (and files under it) in > package_version-rev.diff.gz? I have a lot of other diffs outside debian/ > (in aclocal.m4, Makefile.in,...). The problem is that after I run > ./configure and then make distclean, I don't have the same directory (as > it was before ./configure). Can I ignore this? Install autotools-dev and read its README files. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Removing non-free documentation from a package
On Thu, 15 Sep 2005, Rafael Laboissiere wrote: > Well, the new package will not contain a Perl module, so I do not see the > need to sticking to the conventions (cf section 4.2 of the Debian Perl We know what to guess as its name, that along is good enough reason IMHO. > At any rate, I guess you are suggesting the name > libparse-recdescent-perl-doc-nonfree, aren't you? Good chances to win > the longest-package-name contest in Debian :-) Yes, but that's not a problem (and you can shorten nonfree to nf or somesuch :-) ). -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Removing non-free documentation from a package
On Thu, 15 Sep 2005, Rafael Laboissiere wrote: > I buy Sven's arguments in favor of adding -nonfree. I would also strip the > "lib" at the beginning of the name. The upstream Perl module is called > Parse-RecDescent, so I would call the package parse-recdescent-doc-nonfree. > What do you think? Stick to the perl package naming convention. Please. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: How can I modify /etc/inittab?
On Mon, 12 Sep 2005, Ben Finney wrote: > On 11-Sep-2005, Henrique de Moraes Holschuh wrote: > > Then tell the user that, and DO NOT TOUCH /etc/inittab. > > Unless by using a well-defined interface for doing so. To my Well, a broken inittab is a nightmare to repair for anyone without console access and without some advanced knowledge (init=/bin/bash, repair the crap, exec /sbin/init and so on...). I would really, really prefer if NOTHING attempted to muck with it. A tool to plug to dpkg that parses inittab and refuses to allow the package to uninstall if any of its components is listed there would be handy, tough. Anyway, ask the sysvinit maintainer if he would be amiable to such an interface. If he says 'yes', then bring it up on the initscripts-ng alioth.debian.org project, and we shall attempt to design one. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: How can I modify /etc/inittab?
On Fri, 09 Sep 2005, Joe Smith wrote: > news:[EMAIL PROTECTED] > >Don't. /etc/inittab is critical infrastructure on every system where it is > >used, NEVER EVER touch it. > > > >Document what the user has to do to activate the package, instead, and let > >him activate it where he wants, the way he wants. > > The proper way to activate the package *IS* by changing inittab. Only init Then tell the user that, and DO NOT TOUCH /etc/inittab. > Since there is no interface you must instruct the user to edit the file by > hand. That is all policy allows. If you wish you can file a wishlist bug > against sysvinit. Yes. But AFAIK there are absolutely no plans to provide an interface for ANY package to touch /etc/inittab. Screwing it up is so utterly callous, that one would have to be out of his mind to encourage any package to attempt to "auto configure" anything inside /etc/inittab. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: How can I modify /etc/inittab?
On Fri, 09 Sep 2005, Eddy Petri?or wrote: > The application I want to package, qingy, is in fact a replacement for > getty and it needs to modify /etc/inittab. Don't. /etc/inittab is critical infrastructure on every system where it is used, NEVER EVER touch it. Document what the user has to do to activate the package, instead, and let him activate it where he wants, the way he wants. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: suspicious new e-mail address notification of a contributer
On Sun, 04 Sep 2005, Oohara Yuuma wrote: > to it is not very safe. I have no other way to contact him. > What should I do? If he is a contributor to a package you take care of, write a message there that he must send you a gpg-signed message from his new address. Apparently he does not have a gpg key yet. So, that means he gets to do the "find a DD to sign your key" dance. If he lives in Canada, that should not be difficult to do. Of course, he getting into a keysign with anyone *you* trust personally to not do stupid things when keysigning should be enough. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: linker and transition questions...
On Sat, 03 Sep 2005, Steve Langasek wrote:
> #: mmainwindow.cpp:625
> msgid "5 minutes warning"
> msgstr "5 minutos aguardando"
> - "aguardando" means "waiting", not "warning"
Oh dear. And people ask me why I refuse to have LC_MESSAGES set to pt_BR,
even though it is my native language. I would send a lot of hate mail to
any half-assed translator that left his email address behind...
Never mind any translator worth the air he consumes would have tried to find
out when the program outputs such a message to better translate it, since
"Alerta: 5 minutos" is not good portuguese, you really need to know if it is
5 minutes SINCE something happened ("Alerta: já se passaram 5 minutos"), or
5 minutes TO something happening ("Alerta: faltam 5 minutos").
THIS is the reason why I respect so very few translators to pt_BR.
> #: mstatstab.cpp:96
> msgid "Re&fresh"
> msgstr "Re&iniciar"
> - refresh != restart?
"Reiniciar" is directly equivalent to "restart", indeed. The proper pt_BR
translation for "refresh" in computer-related lingo is "atualizar", which is
a direct equivalent to "update".
> #: mschedulertab.cpp:44
> msgid "Registere&d tasks:"
> msgstr "Registra&dor de tarefas:"
> - "Registrador" means something that is used for registering; this could
> be an ok translation in context, I don't know.
It is ugly. A very sloppy translation, indeed. Just the kind I'd expect to
find on MS-Office localized editions to pt_BR. "Registered tasks" is to be
translated to something like "Tarefas registradas:" or "Tarefas elencadas:",
or even something more specific to the particular usage.
AFAIK, "registrador" is only used for computer architecture registers, or
for some machines that keep records (and the only one I can recall is
"máquina registradora" which is those old mechanical calculators used for
point-of-sales.
> #: msettingsdialog.cpp:430
> msgid "C&ustom Message"
> msgstr "Mensagem P&adrão"
> - Padrão means "default", not "custom"...
Yes. This translator should not be allowed close to a po file for some years
while he learns the language properly (which one he is weak at I don't
know), or never (if it is due to sloppyness).
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
Re: sponsors.debian.net beta
On Thu, 18 Aug 2005, Ben Finney wrote: > This has happened at at least a dozen sites recently. I'm getting > really sick of this. Is everyone using the same frigging regex to > "validate" email addresses? Well, whatever the cause, it's *wrong*. > Please stop "validating" email addresses against a regex. I get that kind of crap everytime I try to use an extended email address with a "+" in most "professionaly run and written corporate sites"... That said, I can't see how your [EMAIL PROTECTED] address could have failed any sort of regex that didn't break everyone else's address... RFC2822 has the BNF for a valid email address. Anyone writing a check must use THAT as a guide and accept 100% of what the RFC deems valid (and reject 100% of what it deems as invalid, as well). -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: autotools during build
On Fri, 12 Aug 2005, Goswin von Brederlow wrote: > On the other hand, if you run them during build then you MUST 'unrun' > them in the clean target. Otherwise every build will get a (potentialy > hugely) different diff.gz file. No. Just rm -f all autogenerated crap in debian/rules's clean target as it is proper. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: autotools during build
On Sat, 13 Aug 2005, Armin Berres wrote: > "You have two good choices, and one bad choice for packaging upstream > source which uses automake and autoconf and contains generated files: > > 1. Tolerate the big diff size, and run the autotools stuff before you > create the debian source package. This is what I usually do. Just to make it a bit more clear, I do not advocate uselees bloating up the .diff file by copying over config.guess and config.sub. Remove them in the clean target, and symlink them (or copy them for no extra brownie points) before calling configure in debian/rules. > Most people proposed to use the 3. choice so far. According to above > document this is not a very good solution. That's a little strange, > isn't it? I stand to what I wrote. IMO, the third choice is the worst possible solution, and so far the reasons for advocating it have been weak at most, IMHO: 1. it bloats the diffs -- not a big deal. Those are compressed, and end up only once in the entire archive. We should be killing a lot of other crap as well if we are to bother with this kind of "bloat". 2. it adds non-interesting things to the diffs -- yes, it does. But it is quite easy to ignore those hunks if you are hunting down the Debian changes. It becomes a problem in certain situations where it is akin to assuming that the maintainer is not being a sneaky bastard and trying to pass something else as an autotools update hunk. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: autotools during build
On Fri, 12 Aug 2005, Steve Langasek wrote: > On Fri, Aug 12, 2005 at 01:50:33PM +0200, Daniel Leidert wrote: > > > Aside from wasting (a little) > > > space in the archive, that makes it harder for NMUers or passing > > > developers > > > to see what's going on in your package. > > > In this case, you could use dpatch to change things and then it is not > > harder to see, what is going on. > > No, it just makes it hard to examine the differences between two versions > using debdiff, rather than making it hard to look at the diff for a single > version. Then we have a design problem with debdiff, don't we? Anyway, for users of dpatch-like packaging methods, that is a non-issue. Using Debian-packaged and fixed autotools (*especially* libtool and gettext) instead of whatever upstream uses is almost always a very good idea in my experience. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: lintian: binary-or-shlib-defines-rpath
On Thu, 09 May 2002, Marc Haber wrote: > From the docs I found, there is no legitimate reason for any package > to define rpath on a Debian system. Is this correct? Does this also > apply to other Linux systems? It is correct for anything that shall end up in the usual ld.so directories. It does not apply to other Linux systems necessarily. > Since linux-atm's configure script does not honor thle --disable-rpath > option and compiles with rpath setting anyway, I'd need to hack the > autoconf/automake scripts and the Makefile templates to remove rpath > to get a lintian clean package. I don't have the necessary knowledge Why not convert it to new autotools (including up-to-date libtool)? That would fix the issue once and for all. > Is it adiviseable to ask upstream to refrain from setting rpath, or am > I being unreasonable here? Setting rpath unconditionally is certainly obnoxious, you could ask them to make it optional. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Source section (debian/control)
On Sat, 30 Apr 2005, Daniel Leidert wrote: > Only that I really understand it: Following your answer, let's say there > is an application which provides some extra functionality, but these > extra-functions need a package outside main to compile. The core > functionality does not need a package outside main. How is this handled? Two source packages, one to main with the non-non-free-requiring functionality, and another to contrib, which only builds whatever requires the non-free bits (maybe depending on the package in main, and using diversions). -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Source section (debian/control)
On Sat, 30 Apr 2005, Daniel Leidert wrote: > need to put the source into contrib/non-free? The situation: I have a > GPL licensed, python based application, which needs python2.3-profiler > (non-free), so the binary package can't go into main. Therefor i will > put it into contrib. Do I have to assign the source as 'contrib' too? Yes. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: How to handle config.guess/sub?
On Sun, 01 May 2005, Carlos Z.F. Liu wrote: > On Sat, Apr 30, 2005 at 11:54:19AM +0200, Goswin von Brederlow wrote: > > Read /usr/share/doc/autotools-dev/README.Debian.gz please. > > > Thanks for the pointer. But it doesn't answer my question. I can't really add documentation on autotools-dev about whatever weirdness people came up with to avoid even thinking about the issue, unless someone remembers to tell me about it! This thread is the first time I read about a build system trying to integrate autotools-dev automatically. That said, I *really* recommend you to simply use the symlink method manually. It is clean, effective, hassle-free and does not bloat the diff or require patches. Heck, the only difference is that after you do a debian/rules clean, you will not have a config.sub or config.guess around, so you will need to use debian/rules build or somesuch to run ./configure while mucking around with the package (or just add them back manually). -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Revision control systems and Debian packages
On Mon, 18 Apr 2005, Milan Zamazal wrote: > >>>>> "HdMH" == Henrique de Moraes Holschuh <[EMAIL PROTECTED]> writes: > > HdMH> or tla-buildpackage (using bazaar, NOT tla) > > Why not tla? I can't condone the braindamaged user interface tla has. Bazaar is at least fixing it to be far more useable. In fact, I can't stand tla while baz (1.3.2) is quite a joy to use, as far as the command line interface goes. So, there is no way I am encouraging people to try tla, let them try to use GNU Arch-like systems at their [current] best... -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Revision control systems and Debian packages
On Wed, 13 Apr 2005, Christoph Berg wrote: > Re: Jamie Jones in <[EMAIL PROTECTED]> > > Can anybody suggest some good revision control systems for maintaining > > Debian packages. I'm about to outgrow using RCS on the debian directory > > and wanted to get an idea of what other maintainers are using for their > > packages. > > svn-buildpackage. or tla-buildpackage (using bazaar, NOT tla) for that matter. Read http://www.dwheeler.com/essays/scm.html to help you make up your mind about which... -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: reassigning bugs
On Wed, 30 Mar 2005, Jeroen van Wolffelaar wrote: > This should be better documented indeed, but most if not all tools Time to file a bug report. What is the package responsible for the BTS documentation on the web? -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: New Package: stellarium
On Sat, 01 Jan 2005, Miriam Ruiz wrote: > Thanks, i'll try to find it. I couldn't find it in > http://packages.debian.org/, and the only package i > found for that program is an old version in > www.apt-get.org. http://snapshot.debian.org: http://snapshot.debian.net/archive/2003/09/15/debian/pool/non-free/s/stellarium/ -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: New Package: stellarium
On Sat, 01 Jan 2005, Miriam Ruiz wrote: > I've just made a new package: Stellarium Astronomy > Software Stellarium was once on Debian, maybe you should have a look on the old package just in case. Especially the changelogs, and any patches. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Patching the upstream sources, and the debian diff
On Mon, 27 Dec 2004, Alejandro Exojo wrote: > because upstream used automake 1.7.6 and unstable now haves 1.7.9 (in > automake1.7). This differences are now added to the diff.gz, but this doesn't > sounds to me the proper way. There is no "proper" way. You have two good choices, and one bad choice IMHO (and I do have a lot of experience on this :P): 1. Tolerate the big diff size, and run the autotools stuff before you create the debian source package (that's what you did, and this is what I usually do). If you do this, go read the README.Debian file of the autotools-dev package *now*. 2. Patch the autotools files (*.in, *.am) at build time, make sure all the build dependencies are 100% correct (hint: conflicting with autoconf2.13 is *always* a good idea if you're not using autoconf 2.13 and automake 1.4). This means that the autobuilders will have to rerun the entire thing, and so will the users, etc. When you're doing a full dpatch-based packaging, this choice makes sense. 3. Live with whatever crap upstream used. You do *not* have this choice if libtool is being used, BTW. And it is a bad choice IMHO, I'm yet to see any distribution with better autoconf, automake, libtool and gettext packages than Debian. > - Is there a preferred way of generating the source and/or the binary package? > - Are not correct the packages that include generated files in the diff? You can avoid *some* generated files getting into the diff, but not always. It is a tradeoff of some disk space, for build time and complexity. Do whatever feels best for you. I'll just recommend that you do not do (3). Please read the autotools-dev README.Debian file. Really. > PS: Grrr, and linda says it's a warning to Build-Depend on automake*, when > clearly many packages have to regenerate their Makefile.in. Linda and lintian can only do so much. Have a look on AM_MAINTAINER_MODE, btw. And read that README.Debian from autotools-dev ;-) -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: indirect build dependencies
On Fri, 24 Dec 2004, Tilman Koschnick wrote: > | Built successfully > | > | NOTE: The package could have used binaries from the following packages > | (access time changed) without a source dependency: > | python-dev: /usr/bin/python > | xlibs-dev: /usr/X11R6/lib/libICE.so /usr/X11R6/lib/libX11.so > /usr/X11R6/lib/libXp.so > > I guess I can ignore the python-dev line, since /usr/bin/python is in package > python. > > What about the xlibs-dev line? Currently, gpsd build-depends on lesstif-dev > and libxaw7-dev, > which pull in the xlibs-dev package. Is this enough, or should I explicitly > depend on xlibs-dev, > or rather libice-dev, libx11-dev, libxp-dev? Do you call any function (directly), or use any header (directly) in libice-dev, libx11-dev, libxp-dev? If yes, then you have to build-depend on them. If no, then you are *not* to build-depend on them. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: (2nd try) RFS: Erudite Directory Service Admin
On Wed, 22 Dec 2004, Mark Roach wrote: > On Wed, 2004-12-22 at 11:41 -0500, Mark Roach wrote: > > On Wed, 2004-12-22 at 23:45 +1100, Matthew Palmer wrote: > > > You can do all of the Debian-specific maintenance in a separate "debian" > > > branch of your revision control system (you do *use* a good revision > > > control > > > system, don't you?) and make regular orig+diff packages. > > FYI, I have switched over to this method. I think it will be simpler to > maintain. The only thing I noticed when building this way is that I get > this warning from dpkg-source > > dpkg-source: warning: ignoring deletion of directory autom4te.cache > dpkg-source: warning: ignoring deletion of file autom4te.cache/traces.0 > dpkg-source: warning: ignoring deletion of file autom4te.cache/requests > dpkg-source: warning: ignoring deletion of file autom4te.cache/output.0 > > Is this something I need to worry about? I could obviously just have > deleted that directory from my original tarball, but I'm curious why > that's happening. Don't ship the autotools cache on your tarball, please. It is begging for trouble. Anyway, that's just patch telling it it cannot remove files, so it left them *untouched* (which is a very, very good reason to make sure your debian/rules clean target rm -f everything of the sort). -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: New upstream packages?
On Sat, 18 Dec 2004, Erinn Clark wrote: > How do you deal with new upstream releases? The general answers I'm getting I'd suggest using a version control system (even a lame one such as CVS), so that you know exactly what changed from one upstream to another, and update the debian/ stuff and any dpatches accordingly. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: ignoring upstream debian directory
On Thu, 28 Oct 2004, Frank Küster wrote: > I see no reason for repackaging in this case. It is much better to just > delete the upstream debian directory in the unpacked sources and copy As I said, diff/patch cannot delete files in a debian package. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh
Re: ignoring upstream debian directory
On Thu, 28 Oct 2004, Frank Küster wrote: > Henrique de Moraes Holschuh <[EMAIL PROTECTED]> schrieb: > > Repack the upstream tarball sans the bogus debian/ dir, or use one of the > > unpack-tarball-on-build-tree/-and-patch packaging styles... > > Why not just replace the upstream debian dir with your version in > diff.gz? Just because some tool (uupdate) might have problems with that? Patch cannot delete files. So, don't trust diff.gz to give you a clean debian/ dir when upstream has some cruft in there. It is dangerous, and potentially much more confusing than one might expect, since you will have to delete bogus files in the clean targed of debian/rules. It will bite the security guys, or someone doing an NMU. Or it will bite you when a new upstream comes that has a dangerous file in debian/ that you didn't notice in time. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh
Re: ignoring upstream debian directory
On Thu, 28 Oct 2004, Frank Küster wrote: > I see no reason for repackaging in this case. It is much better to just > delete the upstream debian directory in the unpacked sources and copy As I said, diff/patch cannot delete files in a debian package. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh
Re: ignoring upstream debian directory
On Thu, 28 Oct 2004, Frank Küster wrote: > Henrique de Moraes Holschuh <[EMAIL PROTECTED]> schrieb: > > Repack the upstream tarball sans the bogus debian/ dir, or use one of the > > unpack-tarball-on-build-tree/-and-patch packaging styles... > > Why not just replace the upstream debian dir with your version in > diff.gz? Just because some tool (uupdate) might have problems with that? Patch cannot delete files. So, don't trust diff.gz to give you a clean debian/ dir when upstream has some cruft in there. It is dangerous, and potentially much more confusing than one might expect, since you will have to delete bogus files in the clean targed of debian/rules. It will bite the security guys, or someone doing an NMU. Or it will bite you when a new upstream comes that has a dangerous file in debian/ that you didn't notice in time. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh
Re: ignoring upstream debian directory
On Thu, 28 Oct 2004, David Everly wrote: > Is there some mechanism or alternative for using uupdate so that any > upstream debian directory can be removed before patching? Repack the upstream tarball sans the bogus debian/ dir, or use one of the unpack-tarball-on-build-tree/-and-patch packaging styles... -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh
Re: ignoring upstream debian directory
On Thu, 28 Oct 2004, David Everly wrote: > Is there some mechanism or alternative for using uupdate so that any > upstream debian directory can be removed before patching? Repack the upstream tarball sans the bogus debian/ dir, or use one of the unpack-tarball-on-build-tree/-and-patch packaging styles... -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: config.sub, config.guess: Why in clean?
On Mon, 25 Oct 2004, Osamu Aoki wrote:
> I have question about handling of config.guess and config.sub in source
> package. I have read autotools-dev README.Debian. So I understand these
> need to be the latest ones whenever we compile the source.
Good :-)
> But why in clean target? This makes large diff.gz with useless patch.
> Why not at the start of config.status after dh_testdir (or include it to
> dh_testdir.)?
Use the link method, it won't increase the diff. It is in the clean target
because there isn't a proper target to transform the source before packing
and after unpacking.
The link method basically rm f config.sub and config.guess on clean (which
mean they will not show up on the diff) and ALSO rm -f them and symlink them
to /usr/share/misc/config.{sub,guess} before calling configure. The price
is a build-depends on autotools-dev. Some people don't like this because
what you get when you initially dpkg-source -x is not exactly what will be
used if you try to dpkg-buildpackage.
> Can anyone point me to where to find ratinale of this practice?
Some people don't like the symlink method, and it is better to have a bigger
diff than to have a permanently static config.sub/guess that will require an
upload later.
> (At least when ever I build with dpkg-buildpackage, it runs clean first
> so this cosmetic difference has no binary impact.)
That's why the clean target was used, since there is no proper target, and
in practice the clean target works.
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
Re: config.sub, config.guess: Why in clean?
On Mon, 25 Oct 2004, Osamu Aoki wrote:
> I have question about handling of config.guess and config.sub in source
> package. I have read autotools-dev README.Debian. So I understand these
> need to be the latest ones whenever we compile the source.
Good :-)
> But why in clean target? This makes large diff.gz with useless patch.
> Why not at the start of config.status after dh_testdir (or include it to
> dh_testdir.)?
Use the link method, it won't increase the diff. It is in the clean target
because there isn't a proper target to transform the source before packing
and after unpacking.
The link method basically rm f config.sub and config.guess on clean (which
mean they will not show up on the diff) and ALSO rm -f them and symlink them
to /usr/share/misc/config.{sub,guess} before calling configure. The price
is a build-depends on autotools-dev. Some people don't like this because
what you get when you initially dpkg-source -x is not exactly what will be
used if you try to dpkg-buildpackage.
> Can anyone point me to where to find ratinale of this practice?
Some people don't like the symlink method, and it is better to have a bigger
diff than to have a permanently static config.sub/guess that will require an
upload later.
> (At least when ever I build with dpkg-buildpackage, it runs clean first
> so this cosmetic difference has no binary impact.)
That's why the clean target was used, since there is no proper target, and
in practice the clean target works.
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
Re: RFS: spampd - a SpamAssassin based SMTP/LMTP scanning proxy daemon
On Sat, 02 Oct 2004, Stephen Gran wrote: > Does postfix not have something like exim's routers?(I really am asking > - I don't know postfix well). I was under the impression that one of > the strengths of it's modularity was that you could plug extra pieces in > in the middle of a routing chain for stuff just like this. No. The modularity is there for security reasons only. You *could* write a router module and plug it somewhere, but that would be C code, and you would need to change the postfix source to do it AFAIK. What postfix allows one to easily plug is output drivers (i.e. the final delivery agent), and filters. Exim's email routing is more versatile than postfix's. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh
Re: [RFS]: pcopy - a replacement for dd
On Sat, 02 Oct 2004, George Danchev wrote: > Desc: Pcopy is intended to be used when doing large disk(partition) to > disk(partition) copying where dd is just too slow (and error prone). When DD is slow, it just mean you should be using raw devices (see the raw command)... :) -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh
Re: RFS: spampd - a SpamAssassin based SMTP/LMTP scanning proxy daemon
On Sat, 02 Oct 2004, Greg Norris wrote: > On Thu, Sep 30, 2004 at 07:41:57PM +0200, martin f krafft wrote: > > And its major disadvantage is that it cannot be configured per-user. > > This makes bayesian filtering kinda useless. > > Are there any Spamassassin based SMTP proxies which can do per-user > bayesian filtering? I've been looking for just such a beastie, but no > luck so far... :-( amavisd-new. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh
Re: RFS: spampd - a SpamAssassin based SMTP/LMTP scanning proxy daemon
On Sat, 02 Oct 2004, Stephen Gran wrote: > Does postfix not have something like exim's routers?(I really am asking > - I don't know postfix well). I was under the impression that one of > the strengths of it's modularity was that you could plug extra pieces in > in the middle of a routing chain for stuff just like this. No. The modularity is there for security reasons only. You *could* write a router module and plug it somewhere, but that would be C code, and you would need to change the postfix source to do it AFAIK. What postfix allows one to easily plug is output drivers (i.e. the final delivery agent), and filters. Exim's email routing is more versatile than postfix's. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [RFS]: pcopy - a replacement for dd
On Sat, 02 Oct 2004, George Danchev wrote: > Desc: Pcopy is intended to be used when doing large disk(partition) to > disk(partition) copying where dd is just too slow (and error prone). When DD is slow, it just mean you should be using raw devices (see the raw command)... :) -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: spampd - a SpamAssassin based SMTP/LMTP scanning proxy daemon
On Sat, 02 Oct 2004, Greg Norris wrote: > On Thu, Sep 30, 2004 at 07:41:57PM +0200, martin f krafft wrote: > > And its major disadvantage is that it cannot be configured per-user. > > This makes bayesian filtering kinda useless. > > Are there any Spamassassin based SMTP proxies which can do per-user > bayesian filtering? I've been looking for just such a beastie, but no > luck so far... :-( amavisd-new. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: cp: `/usr/share/misc/config.sub' and `config.sub' are the same file
On Fri, 01 Oct 2004, Erik Schanze wrote: > > The package I try to debianize is a library, which uses autoconf. Read the entire documents on the package autotools-dev, as well as all the docs on the libtool package (if the lib uses libtool). > The DNMG discourages from debianize a library first. Indeed. Packaging libraries is NOT for those who do not have a firm grasp of how these things plug together. Some experience on packaging other stuff is usually a very good idea before you tack on a library. Most of the time, you CANNOT trust upstream to have done things in a sane way. You have to triple-check it. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh
Re: cp: `/usr/share/misc/config.sub' and `config.sub' are the same file
On Fri, 01 Oct 2004, Erik Schanze wrote: > > The package I try to debianize is a library, which uses autoconf. Read the entire documents on the package autotools-dev, as well as all the docs on the libtool package (if the lib uses libtool). > The DNMG discourages from debianize a library first. Indeed. Packaging libraries is NOT for those who do not have a firm grasp of how these things plug together. Some experience on packaging other stuff is usually a very good idea before you tack on a library. Most of the time, you CANNOT trust upstream to have done things in a sane way. You have to triple-check it. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: UTF-8 in copyright files?
On Thu, 18 Dec 2003, Sven Luther wrote: > I have many locales there, [...] > Should be ok, no ? Yes, it is correct... -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh
Re: UTF-8 in copyright files?
On Thu, 18 Dec 2003, Sven Luther wrote: > I have many locales there, [...] > Should be ok, no ? Yes, it is correct... -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: UTF-8 in copyright files?
On Tue, 16 Dec 2003, Sven Luther wrote: > I choose fr_FR.UTF8 or something such in gnome GDM. And it IS just like that in your /etc/locale.gen as well? fr_FR only won't do. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh
Re: UTF-8 in copyright files?
On Tue, 16 Dec 2003, Sven Luther wrote: > I choose fr_FR.UTF8 or something such in gnome GDM. And it IS just like that in your /etc/locale.gen as well? fr_FR only won't do. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Help with init replacement
Replying to myself. What a shame. Anyway, this whole thread really belongs in debian-devel. On Thu, 20 Nov 2003, Henrique de Moraes Holschuh wrote: > On Thu, 20 Nov 2003, Marc A. Pelletier wrote: > > Hmm; I can see how to make it work if packages register /either/ static > > ordering or dependencies, but not both. > > It must, for backwards compatibility. Once the package has BOTH information > registered, dependencies would take precedence (as in disable the static > ordering). Which is impossible if it must work in the middle of the static ordering chain. Bleh. Anyway, it is not like it matters. Have both static ordering and dependencies active at the same time, but honour them separately. A dependency-based system would already have to track the state of services to be worth something in the first place. There _are_ scenarious where you JUST cannot do anything sensible, but detecting those is also a function the dependency-based system must have, and it must report so to the admin. The transition period would be irksome, but it could be made to work. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh
Re: Help with init replacement
Replying to myself. What a shame. Anyway, this whole thread really belongs in debian-devel. On Thu, 20 Nov 2003, Henrique de Moraes Holschuh wrote: > On Thu, 20 Nov 2003, Marc A. Pelletier wrote: > > Hmm; I can see how to make it work if packages register /either/ static > > ordering or dependencies, but not both. > > It must, for backwards compatibility. Once the package has BOTH information > registered, dependencies would take precedence (as in disable the static > ordering). Which is impossible if it must work in the middle of the static ordering chain. Bleh. Anyway, it is not like it matters. Have both static ordering and dependencies active at the same time, but honour them separately. A dependency-based system would already have to track the state of services to be worth something in the first place. There _are_ scenarious where you JUST cannot do anything sensible, but detecting those is also a function the dependency-based system must have, and it must report so to the admin. The transition period would be irksome, but it could be made to work. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Help with init replacement
On Thu, 20 Nov 2003, Marc A. Pelletier wrote: > Hmm; I can see how to make it work if packages register /either/ static > ordering or dependencies, but not both. It must, for backwards compatibility. Once the package has BOTH information registered, dependencies would take precedence (as in disable the static ordering). > > Don't forget invoke-rc.d either, and if you are mucking with init itself, > > also telinit. > > Daemond doesn't use init.d-style scripts normally. It can be made to (simply > by specifying "init.d/foo start" and "init.d/foo stop" as the service start > and stop) but you loose some functionality this way. [normally, daemond > prefers to invoke daemons in their non-forking operating mode so that it > keeps close tab on the process]. init.d style scripts often do a lot more then just invoking a program. So either init.d always, or a choice selected by the package would be needed. > > > The *correct* way of doing all this, of course, is for packages to create > > > their own service definition file and install them (possibly through some > > > > Nope. The correct way [...] > > I mean correct from /daemond's/ perspective-- if there is a unified method to > have those files generated/installed for it so much the better. I see. > > I actually like the idea of service > > definition files, as long as they are generic > > Well, I /do/ have my own grammar and parser-- the general syntax is similar > from bind's named.conf. I have toyed with the idea of using XML (much as I > despise the tendency of trying to use XML at all costs regardless of how well > it fits the problem set that seems to be prevalent these days) but having > something as critical as one's init depend on large and complex XML libraries > is not my idea of a Good Thing (and rewriting an XML parser just for that > component even sillier). A yacc grammar, OTOH, compiles quite well and > compactly statically. > > You can see a fairly representative of one of my files there: > > http://cvs.sourceforge.net/viewcvs.py/daemond/daemond/doc/sample/daemond.d/syslog?rev=1.1&view=auto > > I think you can figure it out even without docs (except, perhaps, for the > somewhat less obvious "wait" directive-- it simply means that if you > succesfully start "syslogd" (manually or otherwise) you want "klogd" to > be scheduled to start as well if avaliable). > > You can browse around the samples in the CVS tree to get a good idea, and > there is even something that vaguely resembles docs in there. :-) > > > (but I quite dislike the idea > > that one would probably need to run a update-dependency-rc.d or whatever > > script to "transfer" what is in the files to whatever init system is in > > use). > > I don't think there's any way around that; either you need to build a > dependency graph out of statically ordered services, or create a static order > out of a dependency graph-- in either case you need to look (again) at the > entire set to build what is needed for the specific init system. > > But if you use the update-rc.d and dependency-rc.d method that step can be > hidden under the interface, done implicitely. > > > We already have at least one very good dependency-based initscript system > > in Debian, so daemond is not alone in its troubles. > > Oh? Don't know it. Care to point me to it? Sure. Package runit. Also, please read the (now a bit outdated) paper on debian init script systems at http://people.debian.org/~hmh/ -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh
Re: Help with init replacement
On Thu, 20 Nov 2003, Marc A. Pelletier wrote: > Hmm; I can see how to make it work if packages register /either/ static > ordering or dependencies, but not both. It must, for backwards compatibility. Once the package has BOTH information registered, dependencies would take precedence (as in disable the static ordering). > > Don't forget invoke-rc.d either, and if you are mucking with init itself, > > also telinit. > > Daemond doesn't use init.d-style scripts normally. It can be made to (simply > by specifying "init.d/foo start" and "init.d/foo stop" as the service start > and stop) but you loose some functionality this way. [normally, daemond > prefers to invoke daemons in their non-forking operating mode so that it > keeps close tab on the process]. init.d style scripts often do a lot more then just invoking a program. So either init.d always, or a choice selected by the package would be needed. > > > The *correct* way of doing all this, of course, is for packages to create > > > their own service definition file and install them (possibly through some > > > > Nope. The correct way [...] > > I mean correct from /daemond's/ perspective-- if there is a unified method to > have those files generated/installed for it so much the better. I see. > > I actually like the idea of service > > definition files, as long as they are generic > > Well, I /do/ have my own grammar and parser-- the general syntax is similar > from bind's named.conf. I have toyed with the idea of using XML (much as I > despise the tendency of trying to use XML at all costs regardless of how well > it fits the problem set that seems to be prevalent these days) but having > something as critical as one's init depend on large and complex XML libraries > is not my idea of a Good Thing (and rewriting an XML parser just for that > component even sillier). A yacc grammar, OTOH, compiles quite well and > compactly statically. > > You can see a fairly representative of one of my files there: > > http://cvs.sourceforge.net/viewcvs.py/daemond/daemond/doc/sample/daemond.d/syslog?rev=1.1&view=auto > > I think you can figure it out even without docs (except, perhaps, for the > somewhat less obvious "wait" directive-- it simply means that if you > succesfully start "syslogd" (manually or otherwise) you want "klogd" to > be scheduled to start as well if avaliable). > > You can browse around the samples in the CVS tree to get a good idea, and > there is even something that vaguely resembles docs in there. :-) > > > (but I quite dislike the idea > > that one would probably need to run a update-dependency-rc.d or whatever > > script to "transfer" what is in the files to whatever init system is in > > use). > > I don't think there's any way around that; either you need to build a > dependency graph out of statically ordered services, or create a static order > out of a dependency graph-- in either case you need to look (again) at the > entire set to build what is needed for the specific init system. > > But if you use the update-rc.d and dependency-rc.d method that step can be > hidden under the interface, done implicitely. > > > We already have at least one very good dependency-based initscript system > > in Debian, so daemond is not alone in its troubles. > > Oh? Don't know it. Care to point me to it? Sure. Package runit. Also, please read the (now a bit outdated) paper on debian init script systems at http://people.debian.org/~hmh/ -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Help with init replacement
On Tue, 18 Nov 2003, Marc A. Pelletier wrote: > Now /that/ is interresting and smart and is indeed likely the most promising > avenue for quick and dirty daemond integration in debian; the problem is that > from what I have understood, update-rc.d suffers from, by design, exactly the > same problem that rc.d style inits suffer from: no proper way of specifying > dependencies and ordering other than by asigning a cardinal and a set of update-rc.d needs either another interface layer, or a sister command to register dependencies, alright. Want to take on the job? It must be made _very_ generic, a dependency-rc.d (or whatever) that would allow us to plug daemond, as well as the other dependency-based init script systems is very welcome. Don't forget invoke-rc.d either, and if you are mucking with init itself, also telinit. > The *correct* way of doing all this, of course, is for packages to create > their own service definition file and install them (possibly through some Nope. The correct way is to have a proper init system layer that can handle static and dynamic dependencies. I actually like the idea of service definition files, as long as they are generic (but I quite dislike the idea that one would probably need to run a update-dependency-rc.d or whatever script to "transfer" what is in the files to whatever init system is in use). > every package that possibly wants to add themselves to the bootstrap. In No. You just have to add a "compatibility" service that runs the non-dependency-based services as the stock sysv-init rc.d does. Oh, OF COURSE this doesn't give you all the imediate benefits, but it won't break the entire system. > other words, that can't be done before some time after daemond /already/ is > the de facto init process. THAT won't happen easily. OTOH, _IF_ a proper layer is written, tested and deployed, it is feasible to switch all the packages to something that works with it in optimal mode for the release after sarge. We already have at least one very good dependency-based initscript system in Debian, so daemond is not alone in its troubles. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh
Re: Help with init replacement
On Tue, 18 Nov 2003, Marc A. Pelletier wrote: > Now /that/ is interresting and smart and is indeed likely the most promising > avenue for quick and dirty daemond integration in debian; the problem is that > from what I have understood, update-rc.d suffers from, by design, exactly the > same problem that rc.d style inits suffer from: no proper way of specifying > dependencies and ordering other than by asigning a cardinal and a set of update-rc.d needs either another interface layer, or a sister command to register dependencies, alright. Want to take on the job? It must be made _very_ generic, a dependency-rc.d (or whatever) that would allow us to plug daemond, as well as the other dependency-based init script systems is very welcome. Don't forget invoke-rc.d either, and if you are mucking with init itself, also telinit. > The *correct* way of doing all this, of course, is for packages to create > their own service definition file and install them (possibly through some Nope. The correct way is to have a proper init system layer that can handle static and dynamic dependencies. I actually like the idea of service definition files, as long as they are generic (but I quite dislike the idea that one would probably need to run a update-dependency-rc.d or whatever script to "transfer" what is in the files to whatever init system is in use). > every package that possibly wants to add themselves to the bootstrap. In No. You just have to add a "compatibility" service that runs the non-dependency-based services as the stock sysv-init rc.d does. Oh, OF COURSE this doesn't give you all the imediate benefits, but it won't break the entire system. > other words, that can't be done before some time after daemond /already/ is > the de facto init process. THAT won't happen easily. OTOH, _IF_ a proper layer is written, tested and deployed, it is feasible to switch all the packages to something that works with it in optimal mode for the release after sarge. We already have at least one very good dependency-based initscript system in Debian, so daemond is not alone in its troubles. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: config.sub and config.guess | .diff.gz bloat
On Thu, 06 Nov 2003, Zenaan Harkness wrote: > Should I email this to the debhelper script maintainer? No. But you could send a wishlist bug to the dh_make (or debmake, whichever one you used) pakcages to update it. I have changed this thing in autotools-dev' README for quite a while. The old cp way was there to satisfy some weird notion people (and even I, I admit :-) ) had that it was somewhat better to put the dang thing in the sources, since that's what upstream should have been doing anyway. > Even if the program I'm packaging doesn't use autotools If it needs config.sub or config.guess, then you need them in. Otherwise you obviously don't. I suggest you grep for them in your source tree. > (I have a vague understanding that perhaps they're needed > for cross-platform autobuilds and have to stay, but haven't > got a clear answer yet...)? config.sub is needed everywhere autoconf was used (it is called by the configure script). config.guess is often needed as well, either because you don't want users asking why calling ./configure doesn't work, or because you don't call configure properly in your debian/rules file in the first place (HINT: You are to tell it the build and target platforms using info from the proper env. variables). -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh
Re: config.sub and config.guess | .diff.gz bloat
On Thu, 06 Nov 2003, Zenaan Harkness wrote: > Should I email this to the debhelper script maintainer? No. But you could send a wishlist bug to the dh_make (or debmake, whichever one you used) pakcages to update it. I have changed this thing in autotools-dev' README for quite a while. The old cp way was there to satisfy some weird notion people (and even I, I admit :-) ) had that it was somewhat better to put the dang thing in the sources, since that's what upstream should have been doing anyway. > Even if the program I'm packaging doesn't use autotools If it needs config.sub or config.guess, then you need them in. Otherwise you obviously don't. I suggest you grep for them in your source tree. > (I have a vague understanding that perhaps they're needed > for cross-platform autobuilds and have to stay, but haven't > got a clear answer yet...)? config.sub is needed everywhere autoconf was used (it is called by the configure script). config.guess is often needed as well, either because you don't want users asking why calling ./configure doesn't work, or because you don't call configure properly in your debian/rules file in the first place (HINT: You are to tell it the build and target platforms using info from the proper env. variables). -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: config.sub and config.guess | .diff.gz bloat
On Thu, 06 Nov 2003, Zenaan Harkness wrote: > debhelper puts the following into the "clean" rule in debian/rules: > > ifneq "$(wildcard /usr/share/misc/config.sub)" "" > cp -f /usr/share/misc/config.sub config.sub > endif > ifneq "$(wildcard /usr/share/misc/config.guess)" "" > cp -f /usr/share/misc/config.guess config.guess > endif It would be cleaner (for the diff) to: 1. build-depend on autotools-dev 2. use ln -sf instead of cp -f. Of course, for that to work, you HAVE to rm -f both files in the clean target, and do the ln -sf before you call configure. Anyway, whatever you do, you are to keep these files up-to-date. See the autotools-dev readme file. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh
Re: config.sub and config.guess | .diff.gz bloat
On Thu, 06 Nov 2003, Zenaan Harkness wrote: > debhelper puts the following into the "clean" rule in debian/rules: > > ifneq "$(wildcard /usr/share/misc/config.sub)" "" > cp -f /usr/share/misc/config.sub config.sub > endif > ifneq "$(wildcard /usr/share/misc/config.guess)" "" > cp -f /usr/share/misc/config.guess config.guess > endif It would be cleaner (for the diff) to: 1. build-depend on autotools-dev 2. use ln -sf instead of cp -f. Of course, for that to work, you HAVE to rm -f both files in the clean target, and do the ln -sf before you call configure. Anyway, whatever you do, you are to keep these files up-to-date. See the autotools-dev readme file. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: How to deal with bogus bug reports (#197352)
On Tue, 17 Jun 2003, Johannes Rohr wrote: > as you both suggested. But I wonder if the BTS could have an "invalid" > tag for such cases?!? Why clog it up with invalid reports? They stay around as closed for a small while, then get archived... -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh
Re: How to deal with bogus bug reports (#197352)
On Tue, 17 Jun 2003, Johannes Rohr wrote: > as you both suggested. But I wonder if the BTS could have an "invalid" > tag for such cases?!? Why clog it up with invalid reports? They stay around as closed for a small while, then get archived... -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: How to deal with bogus bug reports (#197352)
On Mon, 16 Jun 2003, Johannes Rohr wrote: > What is the generally accepted way within the "Debian culture" to deal > with such reports? Do I close the bug right away? Do I downgrade it? > Do I reassign it (in this case to gstreamer)? You can reassign it with the priority and bug title changed to whatever you find correct. It is the "helpful samaritan" thing to do, since you have actually figured out what was really breaking. Or you can simply close it politely (mail the explanation to -done), and be done with that. It is quite acceptable as well, especially if you didn't have time to track down just what other package was really broken in the first place. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh
Re: How to deal with bogus bug reports (#197352)
On Mon, 16 Jun 2003, Johannes Rohr wrote: > What is the generally accepted way within the "Debian culture" to deal > with such reports? Do I close the bug right away? Do I downgrade it? > Do I reassign it (in this case to gstreamer)? You can reassign it with the priority and bug title changed to whatever you find correct. It is the "helpful samaritan" thing to do, since you have actually figured out what was really breaking. Or you can simply close it politely (mail the explanation to -done), and be done with that. It is quite acceptable as well, especially if you didn't have time to track down just what other package was really broken in the first place. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: How to obtain current package version number?
On Tue, 04 Mar 2003, Bastian Kleineidam wrote: > On Tue, Mar 04, 2003 at 01:41:58PM +0100, Marc Haber wrote: > > how can a package learn about its current version number? > Package information is stored in /var/lib/dpkg/available. No. Do not skip the proper interface layers. Use dpkg to get that information. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh
Re: Packaging the Baramond TTF set
On Tue, 04 Mar 2003, Ivo Marino wrote: > If this font will never be released by the upstream author under a GPL > or BSD like open license but only as freeware is it possibile to include > the package anyway in the contrib or non-free section? Not contrib, unless you package is a simple installer for the fonts. non-free, yes, if the license allows redistribution at all (I didn't check). BTW, please go through the trouble of doing the full defoma stuff when packaging the fonts :) -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh
Re: How to obtain current package version number?
On Tue, 04 Mar 2003, Bastian Kleineidam wrote: > On Tue, Mar 04, 2003 at 01:41:58PM +0100, Marc Haber wrote: > > how can a package learn about its current version number? > Package information is stored in /var/lib/dpkg/available. No. Do not skip the proper interface layers. Use dpkg to get that information. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Packaging the Baramond TTF set
On Tue, 04 Mar 2003, Ivo Marino wrote: > If this font will never be released by the upstream author under a GPL > or BSD like open license but only as freeware is it possibile to include > the package anyway in the contrib or non-free section? Not contrib, unless you package is a simple installer for the fonts. non-free, yes, if the license allows redistribution at all (I didn't check). BTW, please go through the trouble of doing the full defoma stuff when packaging the fonts :) -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: New Maintainer ou New Developer
On Sat, 01 Mar 2003, Agney Lopes Roth Ferraz wrote: > I'm looking for information about debian developer/maintainer. http://nm.debian.org > I read in debian page that the only way to became maintainer is developing > some nice program, but I have two friends that are only who make the .deb > package. Ehh... I couldn't understand that sentence :( If you mean "does one have to be an upstream developer to join Debian", then the answer is "no". But a lot of us (including me) expect you are at least skilled and responsible enough to be an upstream maintainer for your packages, if you are going to take care of packages... (there are other activities in Debian that have little to do with maintaining packages). The procedure is something like this: if you think you're going to stay around for a while, and you have the time, and will to do a lot of work, you are welcome to join. You do that by reading the stuff in nm.debian.org, and showing a lot of work. Then, someone will vouch for you, and you will get started in the NM process (again, see nm.debian.org). If you don't have the time, that's fine. There are lots of ways you can help without sacrificing a lot of time too, but then you should not expend any of that precious time going through the effort of nm.debian.org! Use it to do the work proper, and use the mailinglists to coordinate with someone if you happen to need anything that requires a registered Debian developer. > The situation is: I don't have a nice package develped by me, but I would > like to maintain some package from someone who don't have interest or time > to maintain it on debian. How can I find a package to maintain or how can > I submit a package (not mine) ? Well, find and read the developers' reference. Also, go read the stuff on the debian-br site, and the stuff on www.debian.org/devel. All your answers are there. Don't forget nm.debian.org, either. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh
Re: New Maintainer ou New Developer
On Sat, 01 Mar 2003, Agney Lopes Roth Ferraz wrote: > I'm looking for information about debian developer/maintainer. http://nm.debian.org > I read in debian page that the only way to became maintainer is developing > some nice program, but I have two friends that are only who make the .deb > package. Ehh... I couldn't understand that sentence :( If you mean "does one have to be an upstream developer to join Debian", then the answer is "no". But a lot of us (including me) expect you are at least skilled and responsible enough to be an upstream maintainer for your packages, if you are going to take care of packages... (there are other activities in Debian that have little to do with maintaining packages). The procedure is something like this: if you think you're going to stay around for a while, and you have the time, and will to do a lot of work, you are welcome to join. You do that by reading the stuff in nm.debian.org, and showing a lot of work. Then, someone will vouch for you, and you will get started in the NM process (again, see nm.debian.org). If you don't have the time, that's fine. There are lots of ways you can help without sacrificing a lot of time too, but then you should not expend any of that precious time going through the effort of nm.debian.org! Use it to do the work proper, and use the mailinglists to coordinate with someone if you happen to need anything that requires a registered Debian developer. > The situation is: I don't have a nice package develped by me, but I would > like to maintain some package from someone who don't have interest or time > to maintain it on debian. How can I find a package to maintain or how can > I submit a package (not mine) ? Well, find and read the developers' reference. Also, go read the stuff on the debian-br site, and the stuff on www.debian.org/devel. All your answers are there. Don't forget nm.debian.org, either. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Is sid recommended?
On Wed, 26 Feb 2003, Volker Sturm wrote: > if I want to get into software development for Debian: Is it recommended to > stay with stable or upgrade to sid? If you have to ask, stay with stable. You can use pbuilder to build unstable packages. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh
Re: Is sid recommended?
On Wed, 26 Feb 2003, Volker Sturm wrote: > if I want to get into software development for Debian: Is it recommended to > stay with stable or upgrade to sid? If you have to ask, stay with stable. You can use pbuilder to build unstable packages. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Why are libraries considered bad victims for first packages?
On Tue, 11 Feb 2003, Michael Still wrote: > I have been an open source developer for some time, and am now an > experienced Debian user (a whole week under my belt!). Heh. > I am interested in getting some of my code available as Debian packages, > but the web pages I have been reading imply that it is a bad thing to > attempt a library as a first package. Unfortunately most of my code > depends on libraries which I have also written. Library packaging is difficult to get right when you don't know the gotchas, and require a damn good reading of the debian policy, and packaging guides... also, unless you really know how these things work, you are bound to make mistakes with the shlibs versioning control. You *can* get your software into Debian without doing it yourself (at least at first). Post a RFP (request-for-packaging) bug to wnpp (http://www.debian.org/devel/wnpp), and if someone finds it interesting, he will package it for you. > Why are libraries considered hard to package? Are the problems > insurmountable for a newbiew? No, but you better be ready to study a LOT on how dynamic linking and debian policy re. libraries works first, to minimize trouble. Lintian and linda are your friends, and so is the packaging guide and debian-policy. Also, learning by example is a good idea. Get a well-packaged library and try to understand exactly why everything is done in a certain way... If you can understand how the xfree86 lib packaging is done, you're about ready to package your own without trouble :-) -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh
