Re: dpkg-buildpackage now reorganizing debian/control Depends field??
Hi, On Sun, 24 Feb 2008, Ian Jackson wrote: Raphael Hertzog writes (Re: dpkg-buildpackage now reorganizing debian/control Dependsfield??): I won't revert anything unless you come up with some proof that this causes severe issues that will disturb the lenny release process. I think this is the wrong approach. Surely you should revert the change if people can demonstrate that it's wrong ? Surely. However, in the message that you quoted: 1/ nobody had yet wondered why I made the change and nobody had made any proposal to solve my issues at the same time 2/ Otavio was sort of acknowledging it as a good thing but a good thing that should be delayed for an unknown amount of time waiting for a fix on apt's side while the lack of fix didn't seem to create important problems Under those conditions, I tend to react negatively. :) Given the other (more constructive) exchanges (thanks to Mike Bird, Steve Langasek, Daniel Burrows and Josselin Mouette), I'm willing to revert the change but if we really want to keep 100% determinism, it's not going to be trivial since the dependency simplification code probably needs to be a bit reworked. I'll do by myself: - remove the global sort - sort the output of dpkg-shlibdeps I'd be glad if someone else could help with: - file wishlist bug on any other program creating substitution variables containing dependencies (on top of my mind at least: python-central, python-support, debhelper) - review the simplification code and make it replace the removed dependency by the superseding one if the replaced one appears before the superseding one, otherwise just delete the remove dep and keep the superseding one at his current place - documenting everything (in dpkg-gencontrol(1)/dpkg-source(1)) - that the order within dependencies field is meaningful and will be kept - explain how the simplification of deps is done (That said I'll put it on my TODO list so I might eventually end up doing it) Cheers, -- Raphaël Hertzog Le best-seller français mis à jour pour Debian Etch : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian Configuration Packaging System
Timothy G Abbott tabbott at MIT.EDU writes: Anders Kaseorg and I created a system of CDBS modules (which we've tentatively packaged as the config-package-dev package) for creating Debian configuration packages. By configuration packages, we mean packages that configure an existing Debian system by applying dpkg-divert to configuration files. Our configuration package system makes the process of creating configuration packages efficient. Uh, you can dpkg-divert conffiles, but not generally configuration files, since many won't even be known to dpkg. I must admit I'm a bit sceptical about a proposal on configuration, written by someone who lets this important distinction slip by... Later on you wrote something about symlinks, do you use them, too? Here's one more complication: While I think that preserve local changes also includes the symlink-or-not state of a file and thus must be respected by maintainer scripts, I do not think that this is usually done. In particular, every configuration file handling that was first written for sarge (where sed -i wouldn't work) probably used tempfiles and mv, and I have not seen a single case where the script checked whether it was dealing with a symlink. [...] Since this package is adding a new feature to Debian itself, we think our system should be discussed before we submit an ITP bug. There are some changes to Debian that would enhance the effectiveness of this system, (such as having all packages include md5sums and making ucf interact well with dpkg-divert'ed configuration files), which should perhaps be discussed in this context as well. It's not just ucf, it's also perfectly possible that a maintainer script edits a configuration file, e.g. after debconf prompting, in order to take over user changes from a related package's configuration file, or similar. How do you deal with that? Regards, Frank -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: How to cope with patches sanely
also sprach Manoj Srivastava [EMAIL PROTECTED] [2008.02.25.0828 +0100]: I am not opposed to it. If you can somehow magically create a tool that can linearize the feature branches, more power to you. I personally find the prospect highly unlikely; and I would like to see some code, please, before I grant that such a thing is possible. The tool I envision would simply surf through the history of the integration branch and identify merge commits. Each merge would become a patch in the quilt series. Sure. You can't integrate two features that fundamentally conflict with each other. No amount of smoke and mirrors can obscure that fundamental obstacle. This is independent of the tool set you use. Except that quilt provides the necessary glue to handle it, while feature branches don't. -- .''`. martin f. krafft [EMAIL PROTECTED] : :' : proud Debian developer, author, administrator, and user `. `'` http://people.debian.org/~madduck - http://debiansystem.info `- Debian - when you have better things to do than fixing systems echo '[dO%O+38%O+PO/d00]Fi22os0CC4BA64E418CE7l0xAP' | dc digital_signature_gpg.asc Description: Digital signature (see http://martin-krafft.net/gpg/)
Re: Bits from the DPL: FTP assistants, marketing team, init scripts, elections
On Sun, 24 Feb 2008 13:16:28 +0100 Sam Hocevar [EMAIL PROTECTED] wrote: I would like to set up a Debian Marketing Team, whose work would be to organise all the promotional stuff (logos, t-shirt designs, wallpapers, etc.) so that the project can officially endorse good designs, and to make the ultimate decision on visual stuff such as CD covers, splash screens, etc. This team would have official DPL delegation, but I hope that it can also work with non-Debian-developers, as many packaging teams already do, because the non-DDs know better than us how to draw people to Debian. So please let me know if you are interested, even if you are not a DD, and especially if you are not a programmer! I also would like to spend some Debian money on a contest, similar to the FreeBSD logo contest [2], to create a friendly mascot for the Debian project (in a similar way to the Linux penguin or the GNU gnu) that we can use where the logo is not enough. More on this in a few days. hi together, my name is nico patzold. your mail sounds like a really attractive idea to me: to create a friendly mascot for the Debian project (in a similar way to the Linux penguin or the GNU gnu) I'm finally enthusiastic for debian since etch came out and would like to give something back to the project. I'm not into the technical stuff but trying to convince people (ms users), that debian or linux in general simply is a operating system ;) and it's a good idea to use it! to cut the longway short: I'm iterested, but don't know how it works or how I could contribute. my skills are in graphics, I like drawing and would be pleased to give some ideas for a debian mascott or advertising for debian in general. many greetings, nic -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: git bikeshedding (Re: triggers in dpkg, and dpkg maintenance)
On Mon, 25 Feb 2008, Pierre Habouzit wrote: I vote for clean history and a bissectable tree, and I think it is worth the effort. But I am no dpkg developer, this is a thing you guys have to find an agreement among yourselves. You vote for the mad route. Sorry, but it makes absolutely no sense to me. Ian's work was done at some point, tested from that point, and it makes sense to remember that fact. Actually it's insane to forget that fact. And rebasing is just pretending that fact never existed. It's just wrong. Let me put this straight. I don't want Ian to rebase for the sake of rebasing. I have no problem with merging clean branches. But his branch is not clean: http://git.debian.org/?p=users%2Fiwj%2Fdpkg.gita=searchh=triggersst=authors=Ian+Jackson It starts with two very big commits touching almost all files and is followed by many small commits which have ubuntu changelog entries as commit log (and thus the summary line is useless). It also contains invalid email address in some Author fields. I wanted him to present the history in a way that makes sense to proof-readers and anyone else working on dpkg. Had he developed his branch with care to have something reviewable, I would have zero problem merging his branch without requiring a rebase. Cheers, -- Raphaël Hertzog Le best-seller français mis à jour pour Debian Etch : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: git bikeshedding (Re: triggers in dpkg, and dpkg maintenance)
On Mon, Feb 25, 2008 at 08:38:03AM +, Raphael Hertzog wrote: On Mon, 25 Feb 2008, Pierre Habouzit wrote: I vote for clean history and a bissectable tree, and I think it is worth the effort. But I am no dpkg developer, this is a thing you guys have to find an agreement among yourselves. You vote for the mad route. Sorry, but it makes absolutely no sense to me. Ian's work was done at some point, tested from that point, and it makes sense to remember that fact. Actually it's insane to forget that fact. And rebasing is just pretending that fact never existed. It's just wrong. Let me put this straight. I don't want Ian to rebase for the sake of rebasing. I have no problem with merging clean branches. But his branch is not clean: http://git.debian.org/?p=users%2Fiwj%2Fdpkg.gita=searchh=triggersst=authors=Ian+Jackson It starts with two very big commits touching almost all files and is followed by many small commits which have ubuntu changelog entries as commit log (and thus the summary line is useless). It also contains invalid email address in some Author fields. I wanted him to present the history in a way that makes sense to proof-readers and anyone else working on dpkg. Had he developed his branch with care to have something reviewable, I would have zero problem merging his branch without requiring a rebase. Well, what you want him to do then is not rebasing onto master, because that won't change that a single bit. And indeed I agree this history is a complete mess, and an SCM abuse. What you want him to do is using: git rebase -i his original branch point which will _not_ change where he came from, but only how he presented it, which is a tiny smallish lie about how it was brought to the world, but would make history way better. But again, rebasing onto master will not make that any better, it'll make fresh pooish history instead of the current one. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpXneoFdbb3B.pgp Description: PGP signature
Re: How to cope with patches sanely
On Mon, Feb 25, 2008 at 03:37:07AM +, Manoj Srivastava wrote: On Sun, 24 Feb 2008 21:17:10 -0500, David Nusinow [EMAIL PROTECTED] said: On Sun, Feb 24, 2008 at 06:08:17PM -0800, Russ Allbery wrote: David Nusinow [EMAIL PROTECTED] writes: The problem is that you and Manoj assume that this is the only way to do things. I don't believe this. Pierre Habouzit has been experimenting with an alternative method of feature branches that exports to a linear stack of diffs just fine. Just because Manoj is doing something one way right now doesn't mean it's the only or even the correct way to do it. I would be interested in details of this, and whether this approach works with pure feature branches where the features are being developed contemporaneously with each other an upstream development; and thus the branches overlap both temporally and in code space. I'm planning to write a textual version of what I demonstrated at FOSDEM, with some more ideas that I had talking with Julien Cristau on the grass after. You developped them contemporaneously, okay, but in the end you merge them one after the other. If you're doing criss-cross merges, well, I can nothing for you, and you're creating really messy histories, and yes, you need an SCM to represent that in a satisfying way. But if you really merge one feature branch on top of the other, and it's in my experience *way enough* for what we need in Debian packaging, then multiple branches are just multiple series to be applied in a specific relative order. The problem is, I believe that there are two kind of things: patches that you backport from upstream. If you're lucky enough to have an upstream using git, it's just a matter of merging the stable branch into yours, or cherry-picking some patches, which will not create conflicts when you merge back. This goes in the .diff.gz, and it's okay (at least I think so) because it's patches that _everyone_ can take from upstream as well. You don't need to make them special, and it's always possible to generate some kind of flat file to say, okay, I cherry-picked this patch this patch and this patch from upstream, or merged up to this point of this upstream branch. This information is more useful than the patch series for derived distros, or co-maints. When it comes to specific patches of yours, I really believe that topic branches like you advertise them are the best answer. Git makes merging easy (s/Git/reasonnable $DSCM/ for this matter btw) in the sense that merging is fast enough, and easy enough when the branches you merge have not diverged too much. I mean, no matter which SCM you use, merging from a branch that is _very_ old, and still not merged upstream is jut a pain. And it's again not an SCM issue. A patch queue _is_ a branch in itself. Really. There are two ways to look at that. Either you say, I always want to remember I started from this point, and then you merge and merge and merge, and your history looks like that: R are uptream releases, M your repeated merges to keep the feature branch current. -o---o---o--[...]--R--[...]--R--[...]--o-- \\ \ p--p--p--p---M-M...[feature branch] Well with this approach, upstream will have to take a messy history with a _lot_ of merge points they don't care about, and won't be able to try your feature branch on top of their current work and maybe eventually adopt it. And worse, if you have to add new patches along the way, you get an history with a mixed suite of patches and merges, which is unreadable to upstream. The other way is to forget about giving depth *in* the SCM to the patches history. Because it's what it's about. What you really want IMSHO is: I have this patch queue [pq] and at upstream R0 it was in state pq0, in upstream R1 it was in state pq1 and so on. Without any useless merge points in it. This way your feature branch is a free (as in only attached to history by its base) branch that you rewrite for each new upstream, serialize under debian/patches/featurebranch. In git, there is this awesome git-quiltimport command that allow you to rebuild a branch from a quilt series in a trivial way. If you want to work on the patch queue, you just need to make it a branch again, do your stuff, serialize it again, and you're done. While doing that, your workflow allow people to do meaningful changes to your package (by adding patches to a given queue), that you'll transparently *painlessly* import into your workflow. Whereas with your current one, you'll have to extract whatever the NMUer did that is a flat debdiff, and split it. It's horrible for you, don't please pretend otherwise, I won't believe you. The other gain, is that upstream can look at a current, unencumbered patch queue about the feature you added, and can take a decent decision about the fact that it's good to take upstream or not, and it's trivial to export such a branch to upstream:
Re: [errata] How to cope with patches sanely
On Mon, Feb 25, 2008 at 09:33:48AM +, Pierre Habouzit wrote: When it comes to specific patches of yours, I really believe that I really *don't* believe topic branches like you advertise them are the best answer. Git makes -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpvZAMlJ48La.pgp Description: PGP signature
Re: Debian Configuration Packaging System
Le dimanche 24 février 2008 à 19:46 -0800, Russ Allbery a écrit : The ones that are overwritten completely that I'm aware of contain only settings managed by debconf, or (as is the case for krb5-kdc and krb5-admin-server) explicitly ask whether you want to manage the configuration file through debconf or want to manage it manually so that you can set more obscure options. This is really a bad idea, because you always end up modifying a debconf-managed file by hand. The solution to this problem is to use ucf instead. -- .''`. : :' : We are debian.org. Lower your prices, surrender your code. `. `' We will add your hardware and software distinctiveness to `-our own. Resistance is futile. signature.asc Description: Ceci est une partie de message numériquement signée
Re: How to cope with patches sanely
On Mon, 25 Feb 2008 09:35:13 +0100, martin f krafft [EMAIL PROTECTED] said: also sprach Manoj Srivastava [EMAIL PROTECTED] [2008.02.25.0828 +0100]: I am not opposed to it. If you can somehow magically create a tool that can linearize the feature branches, more power to you. I personally find the prospect highly unlikely; and I would like to see some code, please, before I grant that such a thing is possible. The tool I envision would simply surf through the history of the integration branch and identify merge commits. Each merge would become a patch in the quilt series. How are you planning on doing this identification? Looking at the arch logs, it is not trivial to identify merge commits and the upgrade patches (which are just merges from the upstream branch), unless you start with an ancient version (like, from my 2003 repo) and then apply every single commit to the integration branch over the last five years (with really really huge numbers of patches). You'll have to track repo changes, figure out how to overcome sealed branch boundaries, etc. I am not sure I believe this to be feasible until I see some code. Sure. You can't integrate two features that fundamentally conflict with each other. No amount of smoke and mirrors can obscure that fundamental obstacle. This is independent of the tool set you use. Except that quilt provides the necessary glue to handle it, while feature branches don't. No, it does not. If branch A has pi = 2.34567; and branch B has pi = 3.14159; No matter how much quilting you do you cannot reconcile the fundamental conflict in the final. Either pi is 3.14159; or it is not; and if branch A requires pi not to be that value, and branch B requires pi to be that value, quilt can't make C be quantum like and have the value be both. manoj -- Griffin's Thought: When you starve with a tiger, the tiger starves last. Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bits from the DPL: FTP assistants, marketing team, init scripts, elections
Hi, On Monday 25 February 2008 08:15, Aníbal Monsalve Salazar wrote: On Mon, Feb 25, 2008 at 09:07:20AM +0200, Lars Wirzenius wrote: We had a chicken[¹]. We spent years actively getting rid of it. [¹] Technically speaking it was a penguin. But it was a youthful penguin, rebelling against its genetic heritage. Oh why? I liked the chicken! When I read Sams mail I immediatly thought of it. Maybe it's good idea to renew the drawing (and keep the basic idea/look), but IMHO thats all. And we should definitly keep the swirl as _the_ logo. LCA2009 has a tasmanian devil pretending to be penguin [²]. [²] https://linux.conf.au/ HAHA. Wow, great! regards, Holger pgpVyvyRAI02r.pgp Description: PGP signature
Re: How to cope with patches sanely
On Mon, 25 Feb 2008 10:33:48 +0100, Pierre Habouzit [EMAIL PROTECTED] said: On Mon, Feb 25, 2008 at 03:37:07AM +, Manoj Srivastava wrote: On Sun, 24 Feb 2008 21:17:10 -0500, David Nusinow [EMAIL PROTECTED] said: On Sun, Feb 24, 2008 at 06:08:17PM -0800, Russ Allbery wrote: David Nusinow [EMAIL PROTECTED] writes: The problem is that you and Manoj assume that this is the only way to do things. I don't believe this. Pierre Habouzit has been experimenting with an alternative method of feature branches that exports to a linear stack of diffs just fine. Just because Manoj is doing something one way right now doesn't mean it's the only or even the correct way to do it. I would be interested in details of this, and whether this approach works with pure feature branches where the features are being developed contemporaneously with each other an upstream development; and thus the branches overlap both temporally and in code space. I'm planning to write a textual version of what I demonstrated at FOSDEM, with some more ideas that I had talking with Julien Cristau on the grass after. You developped them contemporaneously, okay, but in the end you merge them one after the other. No, I do not. I developed feature A a bit, merged that. Then I developed feature B a bit, and merged that. Then I developed feature A some more. The there came an upstream version. Then feature B ... If you're doing criss-cross merges, well, I can nothing for you, and you're creating really messy histories, and yes, you need an SCM to represent that in a satisfying way. Thanks. So most of my packages will not get any help from the tool you are talking about -- and thus, it can't be made into a policy requirement. But if you really merge one feature branch on top of the other, and it's in my experience *way enough* for what we need in Debian packaging, then multiple branches are just multiple series to be applied in a specific relative order. But that is not how development happens in long running sets of features, which have been under development, incrementally, over a large number of upstream versions. When it comes to specific patches of yours, I really believe that topic branches like you advertise them are the best answer. Git makes merging easy (s/Git/reasonnable $DSCM/ for this matter btw) in the sense that merging is fast enough, and easy enough when the branches you merge have not diverged too much. I mean, no matter which SCM you use, merging from a branch that is _very_ old, and still not merged upstream is jut a pain. Depends. I keep the topic branches updated with each upstream release, and I have carried fvwm/make/flex patches around for years and several upstream upgrades, and not had much problems. Indeed, most upstream upgrades have taken _no_ manual effort. And it's again not an SCM issue. A patch queue _is_ a branch in itself. Really. There are two ways to look at that. Either you say, I always want to remember I started from this point, and then you merge and merge and merge, and your history looks like that: R are uptream releases, M your repeated merges to keep the feature branch current. -o---o---o--[...]--R--[...]--R--[...]--o-- \ \ \ p--p--p--p---M-M...[feature branch] Right. Well with this approach, upstream will have to take a messy history with a _lot_ of merge points they don't care about, and won't be able to try your feature branch on top of their current work and maybe eventually adopt it. And worse, if you have to add new patches along the way, you get an history with a mixed suite of patches and merges, which is unreadable to upstream. Heh. Most of my upstream are fed just a patch, since lots of them are using CVS. In Git terms, I always rebase my patch on each upstream version, and can then feed a nice, coherent, minimal patch with no real complex history. The other way is to forget about giving depth *in* the SCM to the patches history. Because it's what it's about. What you really want IMSHO is: I have this patch queue [pq] and at upstream R0 it was in state pq0, in upstream R1 it was in state pq1 and so on. Without any useless merge points in it. This way your feature branch is a free (as in only attached to history by its base) branch that you rewrite for each new upstream, serialize under debian/patches/featurebranch. In git, there is this awesome git-quiltimport command that allow you to rebuild a branch from a quilt series in a trivial way. If you want to work on the patch queue, you just need to make it a branch again, do your stuff, serialize it again, and you're done. Err, I see little benefit in doing that; and I think that I prefer my current feature branch mechanism as being less hassle. I periodically build and test each feature branch (this is why having ./debian as a submodule is
Re: [errata] How to cope with patches sanely
On Mon, 25 Feb 2008 10:40:31 +0100, Pierre Habouzit [EMAIL PROTECTED] said: On Mon, Feb 25, 2008 at 09:33:48AM +, Pierre Habouzit wrote: When it comes to specific patches of yours, I really believe that I really *don't* believe topic branches like you advertise them are the best answer. Git makes I think we differ, than. I believe that feature branches are the way to go (if I did not, I suppose I would not have been using them). manoj -- To err is human, to really foul up requires the root password. Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bits from the DPL: FTP assistants, marketing team, init scripts, elections
Am Montag, den 25.02.2008, 12:00 +0100 schrieb Holger Levsen: Hi, On Monday 25 February 2008 08:15, Aníbal Monsalve Salazar wrote: On Mon, Feb 25, 2008 at 09:07:20AM +0200, Lars Wirzenius wrote: We had a chicken[¹]. We spent years actively getting rid of it. [¹] Technically speaking it was a penguin. But it was a youthful penguin, rebelling against its genetic heritage. Oh why? I liked the chicken! When I read Sams mail I immediatly thought of it. Maybe it's good idea to renew the drawing (and keep the basic idea/look), but IMHO thats all. Can anyone please give an URL for this picture? Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bits from the DPL: FTP assistants, marketing team, init scripts, elections
Am Montag, den 25.02.2008, 13:42 +0100 schrieb David Paleino: On Mon, 25 Feb 2008 12:38:07 +0100, Thomas Weber wrote: Am Montag, den 25.02.2008, 12:00 +0100 schrieb Holger Levsen: Hi, On Monday 25 February 2008 08:15, Aníbal Monsalve Salazar wrote: On Mon, Feb 25, 2008 at 09:07:20AM +0200, Lars Wirzenius wrote: We had a chicken[¹]. We spent years actively getting rid of it. [¹] Technically speaking it was a penguin. But it was a youthful penguin, rebelling against its genetic heritage. Oh why? I liked the chicken! When I read Sams mail I immediatly thought of it. Maybe it's good idea to renew the drawing (and keep the basic idea/look), but IMHO thats all. Can anyone please give an URL for this picture? I believe what they're talking about can be seen on http://lintian.debian.org/. (see the penguins on the background of the logo) Thanks. I finally found http://www.debian.org/vote/1999/debianlogo-3.jpg An image of a chicken, picking at 2+ grains and still not sated comes to my mind. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bits from the DPL: FTP assistants, marketing team, init scripts, elections
On Mon, 25 Feb 2008 12:38:07 +0100, Thomas Weber wrote: Am Montag, den 25.02.2008, 12:00 +0100 schrieb Holger Levsen: Hi, On Monday 25 February 2008 08:15, Aníbal Monsalve Salazar wrote: On Mon, Feb 25, 2008 at 09:07:20AM +0200, Lars Wirzenius wrote: We had a chicken[¹]. We spent years actively getting rid of it. [¹] Technically speaking it was a penguin. But it was a youthful penguin, rebelling against its genetic heritage. Oh why? I liked the chicken! When I read Sams mail I immediatly thought of it. Maybe it's good idea to renew the drawing (and keep the basic idea/look), but IMHO thats all. Can anyone please give an URL for this picture? I believe what they're talking about can be seen on http://lintian.debian.org/. (see the penguins on the background of the logo) David -- . ''`. Debian maintainer | http://wiki.debian.org/DavidPaleino : :' : Linuxer #334216 --|-- http://www.hanskalabs.net/ `. `'` GPG: 1392B174 | http://snipr.com/qa_page `- 2BAB C625 4E66 E7B8 450A C3E1 E6AA 9017 1392 B174 signature.asc Description: PGP signature
Idea of Debian mascot
Hi, On Mon, 25 Feb 2008, nic wrote: to cut the longway short: I'm iterested, but don't know how it works or how I could contribute. I don't know what needs to be explained... you don't need any special status to contribue a mascot, just find the idea, create the picture, send it to us and wait feedback. Maybe try several variants. my skills are in graphics, I like drawing and would be pleased to give some ideas for a debian mascott or advertising for debian in general. For an idea of a mascot, maybe you could try some sort of bear. When I created the logo of my company [1], I tried to select an animal that could remind me the strength of Debian and I selected the bear: - walks usually slowly but when it runs, you'd better not be in his way (the quiet force -- we say la force tranquille in French, not sure if I made a good translation) - the white bear could live near the Linux penguin in some cold area Cheers, [1] http://www.freexian.com/images/Logo_Freexian_700x400.png -- Raphaël Hertzog Le best-seller français mis à jour pour Debian Etch : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Idea of Debian mascot
2008/2/25, Raphael Hertzog [EMAIL PROTECTED]: Hi, On Mon, 25 Feb 2008, nic wrote: to cut the longway short: I'm iterested, but don't know how it works or how I could contribute. I don't know what needs to be explained... you don't need any special status to contribue a mascot, just find the idea, create the picture, send it to us and wait feedback. Maybe try several variants. It would be great to have a mascot!! :) Miry -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#467038: RFP: pytrainer -- Free Sport Training Center
On Fri, 22 Feb 2008, David Paleino wrote: sportman resistance like runners, swimmers, skiers, mountain bikers, etc... Pytrainer works with your GPS fitness device and it is be able to Ehm... using a better wording? Hmm, I also care for content. Perhaps I'm to old fashioned but I can't imagine the use of a GPS fitness device for swimmers. ;-) Kind regards Andreas (who did swimming training regularly for 10 years, but before GPS even existed) ;-) -- http://fam-tille.de -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Idea of Debian mascot
Miriam Ruiz [EMAIL PROTECTED] writes: 2008/2/25, Raphael Hertzog [EMAIL PROTECTED]: Hi, On Mon, 25 Feb 2008, nic wrote: to cut the longway short: I'm iterested, but don't know how it works or how I could contribute. I don't know what needs to be explained... you don't need any special status to contribue a mascot, just find the idea, create the picture, send it to us and wait feedback. Maybe try several variants. It would be great to have a mascot!! :) Miry What? You don't have a set of Toy Story Action Figures yet? MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Idea of Debian mascot
hi together, I'm not quite sure how to properly use this debian-list (I should have read before, I know...). I spontaneously thought of an ant: It works hard, it's tough, well, and with a fat grin on its face. just a first idea: the 'debiant'. Just playing with words. I tried some rough sketches, but didn't like them. greets, nic On Mon, 25 Feb 2008 15:34:10 +0100 Goswin von Brederlow [EMAIL PROTECTED] wrote: Miriam Ruiz [EMAIL PROTECTED] writes: 2008/2/25, Raphael Hertzog [EMAIL PROTECTED]: Hi, On Mon, 25 Feb 2008, nic wrote: to cut the longway short: I'm iterested, but don't know how it works or how I could contribute. I don't know what needs to be explained... you don't need any special status to contribue a mascot, just find the idea, create the picture, send it to us and wait feedback. Maybe try several variants. It would be great to have a mascot!! :) Miry What? You don't have a set of Toy Story Action Figures yet? MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dpkg-buildpackage now reorganizing debian/control Depends field??
Raphael Hertzog [EMAIL PROTECTED] writes: 2/ Otavio was sort of acknowledging it as a good thing but a good thing that should be delayed for an unknown amount of time waiting for a fix on apt's side while the lack of fix didn't seem to create important problems Under those conditions, I tend to react negatively. :) I said that I like the idea to have it ordered however, currently, it does mess up with APT and that's why I asked you to revert it until someone (I, Michael or someone else) has time to work on APT and fix it there. -- O T A V I OS A L V A D O R - E-mail: [EMAIL PROTECTED] UIN: 5906116 GNU/Linux User: 239058 GPG ID: 49A5F855 Home Page: http://otavio.ossystems.com.br - Microsoft sells you Windows ... Linux gives you the whole house. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: git bikeshedding (Re: triggers in dpkg, and dpkg maintenance)
Ian Jackson [EMAIL PROTECTED] writes: Raphael Hertzog writes (Re: triggers in dpkg, and dpkg maintenance): However you haven't made it easy to merge your code... you repository is a mess to proof-read and the cleaning work that you don't want to do has thus to be done by Guillem. This is precisely the git bikeshedding I was talking about. The `work' that needs to be done is simply `git pull'. [1] My changes are not that hard to review and in any case they have been ready for merge for SIX MONTHS and deployed in a widely-used released Linux distribution for four months. What more evidence is needed of their suitability ? They're suitable to get in but commit logs and team repository policies need to be respected. I'm with Raphael here and IMHO (even being not a member of team) is that it shouldn't be merge until you, or someone interested, make it follow the policies. FWIW, you do have access to the repository but I would request you to be removed from the team if you made usage of it in a way that doesn't conform to the rules of the team. This includes having meaningful commit logs and using private rebased branches for most of the work except when we have a public branch where multiple persons of the team cooperate (such as what happens with the sourcev3 branch currently). http://wiki.debian.org/Teams/Dpkg/GitUsage This development model has been imported from the Linux kernel. It may be appropriate when there are hundreds or thousands of people generating huge quantities of patches, all trying to get their changes committed, with no organisational connection to the handful of people picked by the original author who need to act as gatekeeper. It is not appropriate for a project which has about four people submitting any significant number of patches, all of whom are fully signed-up members of a shared governance infrastructure, and where the gatekeepers are just the people in that project whose hands the code has most recently fallen into. Sorry but I disagree with you. Every project ought to have sane commit logs and logical changes. It makes cherry-picking, bisect and others much easier and improves the general programming experience of others devels since they see logical commits instead of a bunch of commit doing different changes all the time. Bear on mind that the comment used on the commit ought to be used to justify the commit itself. It's not only to give something to show at git log. -- O T A V I OS A L V A D O R - E-mail: [EMAIL PROTECTED] UIN: 5906116 GNU/Linux User: 239058 GPG ID: 49A5F855 Home Page: http://otavio.ossystems.com.br - Microsoft sells you Windows ... Linux gives you the whole house. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: git bikeshedding (Re: triggers in dpkg, and dpkg maintenance)
Robert Collins [EMAIL PROTECTED] writes: On Sun, 2008-02-24 at 16:46 -0300, Henrique de Moraes Holschuh wrote: Yet, rebasing is still routinely performed in the Linux kernel development. What I find interesting and rather amusing here is Linus talking negatively about rebase: in particular its propensity to turn tested code (what you actually committed) into untested code (what you committed + what someelse has done, in a version of a tree no human has ever evaluated for correctness). If people doesn't test and review the patches after rebasing, it looks right but everyone is suppose to test the changes after a merging (as for rebasing). -- O T A V I OS A L V A D O R - E-mail: [EMAIL PROTECTED] UIN: 5906116 GNU/Linux User: 239058 GPG ID: 49A5F855 Home Page: http://otavio.ossystems.com.br - Microsoft sells you Windows ... Linux gives you the whole house. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: git bikeshedding (Re: triggers in dpkg, and dpkg maintenance)
Pierre Habouzit [EMAIL PROTECTED] writes: ... And AFAICT, the kernel works in the very same way. What gets rebased though, are the bugfixes patches that come by 2 or 3, and that add no value when added as a specific branch. Usually those in git.git are applied on top of the 'maint' branch (aka the maintenance branch) and then merged back into master, and then back into 'next' (where the devel happens). IOW, it depends, and if you work on a new _feature_ it's really rarely rebased. Right. Well said. This however doesn't changes the value of logical changes. I doubt git.git people would accept patches like: Now it compiles again Ouch! Syntax error First try to get it done ... It's much nicer to have something like: Implements the basis for feature 'foo' Changes code to use new feature 'foo' and avoid all the messy commits done in the way. Besides that, I guess that even when you rebase something against git.git or linus tree, you'll end up being out to date and a merging being done since the volume of commits is too high to allow fast-forward merging only. Personaly, when I'm working on any branch I try to keep it against current version (be it maint or next or whatever) rebased. When merging, I don't worry if it'll be a merging or a fast-forward one. It'll only depends on how long the branch took to get merged. I vote for clean history and a bissectable tree, and I think it is worth the effort. But I am no dpkg developer, this is a thing you guys have to find an agreement among yourselves. You vote for the mad route. Sorry, but it makes absolutely no sense to me. Ian's work was done at some point, tested from that point, and it makes sense to remember that fact. Actually it's insane to forget that fact. And rebasing is just pretending that fact never existed. It's just wrong. Please see my commit about the logs above. As I said, it's much more about commit logs (for me at least) then rebasing. If Ian is OK to make it in logical pieces, it would be ok for me to merge. -- O T A V I OS A L V A D O R - E-mail: [EMAIL PROTECTED] UIN: 5906116 GNU/Linux User: 239058 GPG ID: 49A5F855 Home Page: http://otavio.ossystems.com.br - Microsoft sells you Windows ... Linux gives you the whole house. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#467258: general: Net-install CD still defaults to asking for CD in aptitude
Chip Norkus wrote: When installing Debian from the small net-install CD it shouldn't ask for the installation media by default in aptitude. This is small but kind of irritating when working on a fresh debian system in remotely. This is already no longer the case if you use the Lenny installer. Cheers, FJP -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: How to cope with patches sanely
On 25/02/2008, Pierre Habouzit wrote: I'm planning to write a textual version of what I demonstrated at FOSDEM, with some more ideas that I had talking with Julien Cristau on the grass after. Please, pretty please, include graphics. Be it ASCII art-like drawings, or gitk screenshots, with some additional arrows and other comments. Not that I need it, but that would (have been|be) nice. Cheers, -- Cyril Brulebois pgpITYEH0ADJu.pgp Description: PGP signature
Re: git bikeshedding (Re: triggers in dpkg, and dpkg maintenance)
On Sun February 24 2008 1:46:59 pm Henrique de Moraes Holschuh wrote: I vote for clean history and a bissectable tree, and I think it is worth the effort. But I am no dpkg developer, this is a thing you guys have to find an agreement among yourselves. See [1] for why this behavior stinks. Short version: you're throwing away history that may be useful later. My example was: Now, say we started from a common base where line 10 of file X said hi, I locally changed it to foo, upstream changed it to bar, and at merge time I decide that we were both wrong and change it to baz. I don't want to lose the fact that I once had it at foo, in case it turns out later that really was the right decision. [1] http://changelog.complete.org/posts/690-Git-looks-really-nice,-until.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: git bikeshedding (Re: triggers in dpkg, and dpkg maintenance)
On Mon February 25 2008 9:31:15 am Otavio Salvador wrote: Right. Well said. This however doesn't changes the value of logical changes. I doubt git.git people would accept patches like: Now it compiles again Ouch! Syntax error First try to get it done ... It's much nicer to have something like: Implements the basis for feature 'foo' Changes code to use new feature 'foo' and avoid all the messy commits done in the way. Why? I would rather have the original history. After all, isn't that what version control is for? Preserving history? Because perhaps in my attempt to fix a syntax error I inadvertantly messed up some logic that I don't notice until a year later. Perhaps if I then look at $DVCS blame I can see that Ouch! Syntax error changed that logic, and if I then look at the patch, it may be quite easy to see what the syntax error was and how I fixed it incorrectly. One could easily do this hacking on a separate branch, then merge --no-ff into the main branch, and submit that. You'd have one logical top-level commit plus the whole history leading to it if you care. Also, I don't get why git people are so uptight about this. Dirty history is not only tolerated, but the *only* sane option with, lesse... rcs cvs svn darcs tla baz (bzr?) Only the git and hg people seem to care (and the git people a lot more than hg people). -- John -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: the new style mass tirage of bugs
On Thu, Feb 21, 2008 at 02:15:10PM +0100, Mike Hommey wrote: Note that also doesn't indicate how many were actually fixed. We have nothing that look like bugzilla's NOTABUG or INVALID. It would be nice if we had this, actually, and it wouldn't be hard, right? Just define a convention for a new tag? - Td -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Idea of Debian mascot
Le Monday 25 February 2008 15:58:16 nic, vous avez écrit : hi together, I'm not quite sure how to properly use this debian-list (I should have read before, I know...). I spontaneously thought of an ant: It works hard, it's tough, well, and with a fat grin on its face. just a first idea: the 'debiant'. Just playing with words. I tried some rough sketches, but didn't like them. Humm joke And why not a marmot ?? It's a nice beautifull little animal, and, according to WP, Marmots typically live in burrows, and hibernate there through the winter. Most marmots are highly social, and use loud whistles to communicate with one another, especially when alarmed. And, the most important, it is sleeping half of the time ! :-P http://upload.wikimedia.org/wikipedia/commons/3/3b/Marmot-edit1.jpg /joke Romain
Extending fortunes-debian-hints package
Hi all,
I have adopted package fortunes-debian-hints (#465936). The package
contains various 'hints' regarding Debian system as name of package
suggested.
I therefore request to send 'hints' you encountered during your
experience with Debian till now which can be helpful to our users and
developers. Feel free to pass it to me for adding your hints into
package.
Once, enough hints are gathered, I will request for translation of it
too, sometime in near future.
Thanks in advance.
--
Cheers,
Kartik Mistry | GPG: 0xD1028C8D | IRC: kart_
{ftbfs,kartikm}.wordpress.com
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: git bikeshedding (Re: triggers in dpkg, and dpkg maintenance)
John Goerzen [EMAIL PROTECTED] writes: Dirty history is not only tolerated, but the *only* sane option with, lesse... rcs cvs svn darcs tla baz (bzr?) Only the git and hg people seem to care (and the git people a lot more than hg people). After you get used to get branches with proper commits for review, you see the pros. It is much easier to everyone to handle it. It's clearer for someone looking when it has been done and he has a logical unit doing the change instead of 10 commits with messed log messages without visual relation but doing a single logical change. As I said before, I usually commit very ofthen. After the change is done I redo the branch splitting the change in logical units. Each change has a nice and well descripted comment that gives good information to everyone interested on it. -- O T A V I OS A L V A D O R - E-mail: [EMAIL PROTECTED] UIN: 5906116 GNU/Linux User: 239058 GPG ID: 49A5F855 Home Page: http://otavio.ossystems.com.br - Microsoft sells you Windows ... Linux gives you the whole house. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Idea of Debian mascot
On ma, 2008-02-25 at 15:58 +0100, nic wrote: hi together, I'm not quite sure how to properly use this debian-list (I should have read before, I know...). I spontaneously thought of an ant: It works hard, it's tough, well, and with a fat grin on its face. just a first idea: the 'debiant'. Just playing with words. I tried some rough sketches, but didn't like them. I've worked for a company named after an ant hill, whose logo was an ant, and whose justification for those were that the employees were like worker ants, that is, insignificant and trivially replaceable. This did not make us employees feel at all motivated. I'd really rather see something nicer than an ant as a mascot. :) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: How to cope with patches sanely
On Mon, Feb 25, 2008 at 04:06:31PM +, Cyril Brulebois wrote: On 25/02/2008, Pierre Habouzit wrote: I'm planning to write a textual version of what I demonstrated at FOSDEM, with some more ideas that I had talking with Julien Cristau on the grass after. Please, pretty please, include graphics. Be it ASCII art-like drawings, or gitk screenshots, with some additional arrows and other comments. Not that I need it, but that would (have been|be) nice. That's exactly the plan. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpvfCOA8DotC.pgp Description: PGP signature
Re: Idea of Debian mascot
On lun, 2008-02-25 at 16:25 +0100, Romain Beauxis wrote: And why not a marmot ?? It's a nice beautifull little animal, and, according to WP, Marmots typically live in burrows, and hibernate there through the winter. Most marmots are highly social, and use loud whistles to communicate with one another, especially when alarmed. Given that our admin is already a weasel and our browser is an ice weasel, it would only be logical to use this fluffy and beautiful animal as a mascot. -- .''`. : :' : We are debian.org. Lower your prices, surrender your code. `. `' We will add your hardware and software distinctiveness to `-our own. Resistance is futile. signature.asc Description: Ceci est une partie de message numériquement signée
Re: Debian Configuration Packaging System
Josselin Mouette [EMAIL PROTECTED] writes: Le dimanche 24 février 2008 à 19:46 -0800, Russ Allbery a écrit : The ones that are overwritten completely that I'm aware of contain only settings managed by debconf, or (as is the case for krb5-kdc and krb5-admin-server) explicitly ask whether you want to manage the configuration file through debconf or want to manage it manually so that you can set more obscure options. This is really a bad idea, because you always end up modifying a debconf-managed file by hand. The solution to this problem is to use ucf instead. Reading the ucf man page, I don't understand how it would help me for the case of those two packages. But I may be suffering from insufficient imagination. The problem is this: both krb5-kdc and krb5-admin-server have /etc/default files that control various aspects of the startup of the servers, such as whether a krb524d is run and what level of Kerberos v4 support is enabled in the KDC. All of those parameters are prompted for by debconf if you select manage my configuration with Debconf and a corresponding /etc/default file is written out. This lets people get the benefit of translated prompts for the possible options. However, people have also requested an escape hatch to pass arbitrary options to the daemon without having to modify the init script, using the semi-standard DAEMON_ARGS setting in the /etc/default file. ucf, from its DESCRIPTION in its man page, seems to handle the case of shipping a configuration file upstream that may also be locally modified, but I don't see where it handles merging in the results of debconf prompting. Am I just missing something? The approach taken right now is that the user chooses whether the file is debconf-managed or not debconf-managed, and a comment at the top of the file tells the user to pick. Debconf-managed configuration seems to be pretty common in Debian, although I know that some things that are common still aren't good ideas and I'm happy to switch to something better. (There are various bits of debconf cleanup in the krb5 packages that needs to be done, so now's a good time to tell me how the whole thing *should* work so that I can do it all at once.) -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/
Unable to su as a user, I get: Cannot execute /bin/bash: Permission denied
I am logged in as root, and i try to su as a user : user1 ; I get the following error: rmachine:/home/user1/Maildir/cur# su user1 Cannot execute /bin/bash: Permission denied
Re: git bikeshedding (Re: triggers in dpkg, and dpkg maintenance)
On Mon, 2008-02-25 at 10:19 -0600, John Goerzen wrote: Dirty history is not only tolerated, but the *only* sane option with, lesse... rcs cvs svn darcs tla baz (bzr?) bzr supports both ways of working, either cleaning up, or preserving the history as is. It has rebase support through a plugin, but I don't think it's widely used yet. Thanks, James -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: git bikeshedding (Re: triggers in dpkg, and dpkg maintenance)
On Mon, 25 Feb 2008, John Goerzen wrote: On Mon February 25 2008 9:31:15 am Otavio Salvador wrote: Right. Well said. This however doesn't changes the value of logical changes. I doubt git.git people would accept patches like: Now it compiles again Ouch! Syntax error First try to get it done ... It's much nicer to have something like: Implements the basis for feature 'foo' Changes code to use new feature 'foo' and avoid all the messy commits done in the way. Why? I would rather have the original history. After all, isn't that what version control is for? Preserving history? No! Version control is for enhanced traceability of changes, to let one revert easily to previous working states of something, to aid debugging, to ease team work and further development, to (when possible) follow the flow of the code changes in the past, and to keep a lot of useful (when the developer does his job right) metadata along with the changes (i.e. the changelog). Preserving history is part of it, but not the objective. Sometimes you just have to plain clean up the mess, so as to be able to see anything of value through 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: Debian Configuration Packaging System
Josselin Mouette [EMAIL PROTECTED] writes: On lun, 2008-02-25 at 10:23 -0800, Russ Allbery wrote: ucf, from its DESCRIPTION in its man page, seems to handle the case of shipping a configuration file upstream that may also be locally modified, but I don't see where it handles merging in the results of debconf prompting. Am I just missing something? ucf can easily be fed with the debconf-generated file. When told to with the proper option, it will even do a three-way merge of the proposed (maintainer + debconf) changes to the locally modified file. Oh! Okay, that was the piece that I was missing. That's a better solution than what I have now. Thanks, I'll try to find time to look at this in the not-too-distant future. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bits from the DPL: FTP assistants, marketing team, init scripts, elections
Manoj Srivastava [EMAIL PROTECTED] writes: On Mon, 25 Feb 2008 09:07:20 +0200, Lars Wirzenius [EMAIL PROTECTED] said: We had a chicken[1]. We spent years actively getting rid of it. I loved the chicken. I had a character. That would be the animal at: http://lintian.debian.org/ yes? :) -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian Configuration Packaging System
On lun, 2008-02-25 at 10:23 -0800, Russ Allbery wrote: The problem is this: both krb5-kdc and krb5-admin-server have /etc/default files that control various aspects of the startup of the servers, such as whether a krb524d is run and what level of Kerberos v4 support is enabled in the KDC. All of those parameters are prompted for by debconf if you select manage my configuration with Debconf and a corresponding /etc/default file is written out. This lets people get the benefit of translated prompts for the possible options. However, people have also requested an escape hatch to pass arbitrary options to the daemon without having to modify the init script, using the semi-standard DAEMON_ARGS setting in the /etc/default file. This is one of the standard ucf use cases. ucf, from its DESCRIPTION in its man page, seems to handle the case of shipping a configuration file upstream that may also be locally modified, but I don't see where it handles merging in the results of debconf prompting. Am I just missing something? ucf can easily be fed with the debconf-generated file. When told to with the proper option, it will even do a three-way merge of the proposed (maintainer + debconf) changes to the locally modified file. -- .''`. : :' : We are debian.org. Lower your prices, surrender your code. `. `' We will add your hardware and software distinctiveness to `-our own. Resistance is futile. signature.asc Description: Ceci est une partie de message numériquement signée
Re: Extending fortunes-debian-hints package
2008/2/25, Kartik Mistry [EMAIL PROTECTED]: Hi all, I have adopted package fortunes-debian-hints (#465936). The package contains various 'hints' regarding Debian system as name of package suggested. I therefore request to send 'hints' you encountered during your experience with Debian till now which can be helpful to our users and developers. Feel free to pass it to me for adding your hints into package. Would it make sense to make a page in the wiki about it? That might make it easier for people to add hints :) Miry -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Re: Idea of Debian mascot
hi, I tried to send 2 messages but I guess they failed because of the attached files (~ 6 mb)? so where can I put the drafts? citation below. nic hi, here are 2 drafts attached. the debi-ant and the 'ameisenbaer' (ant-eater). look at http://de.wikipedia.org/wiki/Bild:Anteater01.jpeg to compare. just to combine the ideas of an ant and a bear ;) greets, nic -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: the new style mass tirage of bugs
On Mon, 25 Feb 2008, Theodore Tso wrote: On Thu, Feb 21, 2008 at 02:15:10PM +0100, Mike Hommey wrote: Note that also doesn't indicate how many were actually fixed. We have nothing that look like bugzilla's NOTABUG or INVALID. It would be nice if we had this, actually, and it wouldn't be hard, right? Just define a convention for a new tag? Yes; if anyone wants tags like this (or other tags) added, just start using usertags for them, and once there are a couple people or packages using these tags, open a wishlist bug to add the tag with a list of the bugs and a suggested description of the tag suitable for inclusion in the documentation. Don Armstrong -- America was far better suited to be the World's Movie Star. The world's tequila-addled pro-league bowler. The world's acerbic bi-polar stand-up comedian. Anything but a somber and tedious nation of socially responsible centurions. -- Bruce Sterling, _Distraction_ p122 http://www.donarmstrong.com http://rzlab.ucr.edu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Idea of Debian mascot
On lun, 2008-02-25 at 19:24 +0100, Josselin Mouette wrote: Given that our admin is already a weasel and our browser is an ice weasel, it would only be logical to use this fluffy and beautiful animal as a mascot. And (real) foxes are great! -- Corsac signature.asc Description: This is a digitally signed message part
Re: git bikeshedding (Re: triggers in dpkg, and dpkg maintenance)
Henrique de Moraes Holschuh [EMAIL PROTECTED] writes: Preserving history is part of it, but not the objective. Sometimes you just have to plain clean up the mess, so as to be able to see anything of value through it. As people ofthen do when using file based ChangeLog. People doesn't put: Fix my 3rd syntax error today on it. It's used to track useful changes and logical changes. Same for history. -- O T A V I OS A L V A D O R - E-mail: [EMAIL PROTECTED] UIN: 5906116 GNU/Linux User: 239058 GPG ID: 49A5F855 Home Page: http://otavio.ossystems.com.br - Microsoft sells you Windows ... Linux gives you the whole house. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: git bikeshedding (Re: triggers in dpkg, and dpkg maintenance)
On Mon, 2008-02-25 at 17:58 +, James Westby wrote: On Mon, 2008-02-25 at 10:19 -0600, John Goerzen wrote: Dirty history is not only tolerated, but the *only* sane option with, lesse... rcs cvs svn darcs tla baz (bzr?) bzr supports both ways of working, either cleaning up, or preserving the history as is. It has rebase support through a plugin, but I don't think it's widely used yet. The bzr community doesn't encourage rebase because of the destructive effect it has on collaboration - and at least the authors of bzr consider one of its primary goals being to enable collaboration between software authors. So rebase is there for folk that need it, but its not the recommended solution to the various problems mentioned in this thread. -Rob -- GPG key available at: http://www.robertcollins.net/keys.txt. signature.asc Description: This is a digitally signed message part
conditional dependency?
Hi
I maintain libetpan package, which build-depends on libcurl4-gnutls-dev.
Resulting library package dependency is calculated using ${shlib:Depends},
however libdev package dependency on libcurl4-gnutls-dev is manually
written in debian/control file. The build package dependency is valuable
since -lcurl is among 'libetpan-config --ldflags' output.
I've got a wishlist report (#467297), where reporter asks to add
alternative dependency libcurl3-gnutls-dev for better backporting support.
While it is easy for build-dependency (just use libcurl4-gnutls-dev |
libcurl3-gnutls-dev), I see a problem here with libdev package dependency.
It should depend not on libcurl4-gnutls-dev | libcurl3-gnutls-dev, but on
exact one that was actually used when building package.
How to handle this properly?
Nikita
signature.asc
Description: This is a digitally signed message part.
Re: conditional dependency?
On Mon, Feb 25, 2008 at 10:56:09PM +0300, Nikita V. Youshchenko wrote:
Hi
I maintain libetpan package, which build-depends on libcurl4-gnutls-dev.
Resulting library package dependency is calculated using ${shlib:Depends},
however libdev package dependency on libcurl4-gnutls-dev is manually
written in debian/control file. The build package dependency is valuable
since -lcurl is among 'libetpan-config --ldflags' output.
I've got a wishlist report (#467297), where reporter asks to add
alternative dependency libcurl3-gnutls-dev for better backporting support.
While it is easy for build-dependency (just use libcurl4-gnutls-dev |
libcurl3-gnutls-dev), I see a problem here with libdev package dependency.
It should depend not on libcurl4-gnutls-dev | libcurl3-gnutls-dev, but on
exact one that was actually used when building package.
How to handle this properly?
Just trim -lcurl from libetpan-config's output and remove the dependency
altogether.
Obviously, don't do this if libetpan's reverse deps *need* to build with
-lcurl (which is unlikely)
Mike
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: conditional dependency?
On Mon, Feb 25, 2008 at 10:56:09PM +0300, Nikita V. Youshchenko wrote:
I maintain libetpan package, which build-depends on libcurl4-gnutls-dev.
Resulting library package dependency is calculated using ${shlib:Depends},
however libdev package dependency on libcurl4-gnutls-dev is manually
written in debian/control file. The build package dependency is valuable
since -lcurl is among 'libetpan-config --ldflags' output.
I've got a wishlist report (#467297), where reporter asks to add
alternative dependency libcurl3-gnutls-dev for better backporting support.
While it is easy for build-dependency (just use libcurl4-gnutls-dev |
libcurl3-gnutls-dev), I see a problem here with libdev package dependency.
It should depend not on libcurl4-gnutls-dev | libcurl3-gnutls-dev, but on
exact one that was actually used when building package.
How to handle this properly?
Fix libetpan-config on Debian to not return libraries that are only related
to static linking, and drop libcurl4-gnutls-dev to a Recommends?
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
[EMAIL PROTECTED] [EMAIL PROTECTED]
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Looking for co-maintainer for mercurial
On 24-Feb-08, 10:30 (CST), Vincent Danjean [EMAIL PROTECTED] wrote: mercurial in now imported in the PAPT repo: Vcs-Svn: svn://svn.debian.org/python-apps/packages/mercurial/trunk Oh, the irony. Steve -- Steve Greenland The irony is that Bill Gates claims to be making a stable operating system and Linus Torvalds claims to be trying to take over the world. -- seen on the net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: conditional dependency?
While it is easy for build-dependency (just use libcurl4-gnutls-dev | libcurl3-gnutls-dev), I see a problem here with libdev package dependency. It should depend not on libcurl4-gnutls-dev | libcurl3-gnutls-dev, but on exact one that was actually used when building package. How to handle this properly? Just trim -lcurl from libetpan-config's output and remove the dependency altogether. Obviously, don't do this if libetpan's reverse deps *need* to build with -lcurl (which is unlikely) And what if somebody will try to link statically? Although not very probably, until now Debian used to support static linking (libdev packages provide .a files, and depend on libdev packages that provide dependent .a files). signature.asc Description: This is a digitally signed message part.
Re: conditional dependency?
On Mon, Feb 25, 2008 at 11:48:21PM +0300, Nikita V. Youshchenko wrote: While it is easy for build-dependency (just use libcurl4-gnutls-dev | libcurl3-gnutls-dev), I see a problem here with libdev package dependency. It should depend not on libcurl4-gnutls-dev | libcurl3-gnutls-dev, but on exact one that was actually used when building package. How to handle this properly? Just trim -lcurl from libetpan-config's output and remove the dependency altogether. Obviously, don't do this if libetpan's reverse deps *need* to build with -lcurl (which is unlikely) And what if somebody will try to link statically? Although not very probably, until now Debian used to support static linking (libdev packages provide .a files, and depend on libdev packages that provide dependent .a files). Add a --static flag to libetpan-config. Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: conditional dependency?
On Mon, Feb 25, 2008 at 23:48:21 +0300, Nikita V. Youshchenko wrote: Although not very probably, until now Debian used to support static linking (libdev packages provide .a files, and depend on libdev packages that provide dependent .a files). That's not true, afaik. If you're linking statically, you have to figure out dependencies on your own. Cheers, Julien -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Looking for co-maintainer for mercurial
Vincent Danjean wrote: mercurial in now imported in the PAPT repo: Vcs-Svn: svn://svn.debian.org/python-apps/packages/mercurial/trunk Vcs-Browser: http://svn.debian.org/wsvn/python-apps/packages/mercurial/trunk Please add a / at the end (at least for VCS-Browser, which does not really work without). Also fix the wording in changelog: 'Scv-*' should be 'Vcs-*' BTW, I think that hg is now the only VCS package which is not maintained in its own VCS format. (or are there other packages, too?) -- Julian Andres Klode, Fellow of the Free Software Foundation Europe Ubuntu Member | Debian Maintainer | Developer try Ubuntu: http://www.ubuntu.com/ | my site: http://jak-linux.org/ mail: [EMAIL PROTECTED] | IRC: juliank languages: German | English signature.asc Description: OpenPGP digital signature
Re: Looking for co-maintainer for mercurial
[migrating to -curiosa] Julian Andres Klode [EMAIL PROTECTED] writes: BTW, I think that hg is now the only VCS package which is not maintained in its own VCS format. (or are there other packages, too?) $ apt-cache showsrc rcs | grep Vcs Vcs-Browser: http://git.debian.org/?p=users/rfrancoise/rcs.git Vcs-Git: git://git.debian.org/git/users/rfrancoise/rcs.git I can't say I entirely blame its maintainer, though. ;-) -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/[EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
ANNOUNCEMENT: debimg - debian-cd in Python
Dear Debian Developers (and other readers), debimg will be a free alternative to debian-cd, written in Python. Attached are the file lenny.list, which is a data file (see comments in file), and debimg.cfg which is the main configuration file. Please tell me if you do not like one the listed things. Short overview -- 1. dists/**/Packages files are created from the apt cache instead of scanning the pool on the disk (faster) 2. The configuration which packages will be included is stored in one list per debian release. 3. Packages can be included based on Priority, Task and name. This means that there won't be statically generated task files anymore. You can restrict this to specific architectures only, using 'pkgname [architectures]'. 4. debimg is GPL 3 and newer 5. debimg builds netinst disks in about 20 seconds 6. debimg uses apt for dependency solving and downloading License --- Copyright (C) 2008 Julian Andres Klode [EMAIL PROTECTED] This program is free software: you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation, either version 3 of the License, or (at your option) any later version. This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details. Current status -- debimg can build complete disks, but can not split disks or build multi-arch images. It is not released yet, because the code needs some cleanup first. The next steps will be: disk splitting, multi-arch disks, source disks, architectures other than i386 and amd64, gpg signing, etc. Speed - debimg should build netinst disks in about 10-15 seconds, but my current tree does not add documentation to the image yet. How does it work? - debimg uses python-apt functions for downloading files, solving dependencies and parsing the data files Using python-apt to solve dependencies instead of writing an own dependency solver is better, because python-apt's solver is the apt solver written in C. This also leads to a problem, because the C parser does not ignore Conflicts, but this is needed for building disks. At the moment, there is a workaround which simply removes all Conflicts lines from the downloaded Packages files. My wishlist - 1) Automatically build additional (netinst + businesscard) images of testing using debimg on a debian server - (after the release of debimg 0.1) - this version should be able to build netinst + businesscard images without problems Links - Blog: http://juliank.wordpress.com/2008/02/25/debimg-debian-cd-in-python/ -- Julian Andres Klode, Fellow of the Free Software Foundation Europe Ubuntu Member | Debian Maintainer | Developer try Ubuntu: http://www.ubuntu.com/ | my site: http://jak-linux.org/ mail: [EMAIL PROTECTED] | IRC: juliank languages: German | English # Configuration file for debimg CODENAME = lenny MEDIATYPE = netinst MIRROR = http://cdimage.debian.org/debian/ COMPONENTS = main NDISKS = 1 DATA_PATH = ../data/%(CODENAME)s.list UDEB_INCLUDE = netinst UDEB_EXCLUDE = netinst ARCHITECTURE = amd64 DI_GTK_ENABLED = True DI_CODENAME= %(CODENAME)s OUTPATH= debian-%(CODENAME)s-%(ARCHITECTURE)s-netinst.iso # lenny.list - Package list for building Debian images # # # This format follows the RFC-822 specification, with the exception that lines # starting with '#' are ignored. Also, everything after an # is ignored. # # This file contains all specifications previously contained in data/, but in a # more simple and shorter way. Please keep all list sorted alphabetically. # # The control fields # --- # # Package-List: #= The name of the list. Used to find the list # Inherits: #= Include all options from the named list # Priority / Task: #= Include packages based on their priority or task # Depends, Recommends, Conflicts: #= They are parsed like Build-Depends in a source package. Build fails if # one package listed in depends is not available or one package in # conflicts is installed. No version operator supported yet. # Include-Udeb, Exclude-Udeb: #= You may specify a list of regular expressions matching udeb names Package-List: businesscard Include-Udeb: ^.*$ Exclude-Udeb: ^.*$ # This list is used to build a classical netinst disk. Package-List: netinst Inherits: businesscard Priority: required, important Depends: acpid, aptitude, bpalogin, console-cyrillic, console-data, console-terminus, console-tools, cryptsetup, debconf-english, discover1 [i386 amd64], #Hardware detection 1.0 (Conflicts with
Re: conditional dependency?
On Mon, Feb 25, 2008 at 11:48:21PM +0300, Nikita V. Youshchenko wrote: While it is easy for build-dependency (just use libcurl4-gnutls-dev | libcurl3-gnutls-dev), I see a problem here with libdev package dependency. It should depend not on libcurl4-gnutls-dev | libcurl3-gnutls-dev, but on exact one that was actually used when building package. How to handle this properly? Just trim -lcurl from libetpan-config's output and remove the dependency altogether. Obviously, don't do this if libetpan's reverse deps *need* to build with -lcurl (which is unlikely) And what if somebody will try to link statically? Although not very probably, until now Debian used to support static linking (libdev packages provide .a files, and depend on libdev packages that provide dependent .a files). Add a --static flag to libetpan-config. How will this make dependency unneeded? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Idea of Debian mascot
On Mon, Feb 25, 2008 at 04:25:06PM +0100, Romain Beauxis wrote: Humm joke And why not a marmot ?? Screw marmots. What about a human? I would suggest this one: http://people.debian.org/~amaya/wallpapers/dsc01074.jpg -- 1KB // Microsoft corollary to Hanlon's razor: // Never attribute to stupidity what can be // adequately explained by malice. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: conditional dependency?
On Mon, Feb 25, 2008 at 10:56:09PM +0300, Nikita V. Youshchenko wrote:
I maintain libetpan package, which build-depends on libcurl4-gnutls-dev.
Resulting library package dependency is calculated using
${shlib:Depends}, however libdev package dependency on
libcurl4-gnutls-dev is manually written in debian/control file. The build
package dependency is valuable since -lcurl is among 'libetpan-config
--ldflags' output.
I've got a wishlist report (#467297), where reporter asks to add
alternative dependency libcurl3-gnutls-dev for better backporting
support.
While it is easy for build-dependency (just use libcurl4-gnutls-dev |
libcurl3-gnutls-dev), I see a problem here with libdev package
dependency. It should depend not on libcurl4-gnutls-dev |
libcurl3-gnutls-dev, but on exact one that was actually used when
building package.
How to handle this properly?
Fix libetpan-config on Debian to not return libraries that are only
related to static linking, and drop libcurl4-gnutls-dev to a Recommends?
This looks against how librarieshave been packaged in the past.
In particular, Debian Library Packaging guide [0], sec 6.2, states that
libdev package should depend on all libdev packages that the library
package directly depends upon.
Did something change recently?
Maybe I missed something?
Coukd you please provide any pointers to how libraries should be packaged
today?
[0] http://www.netfort.gr.jp/~dancer/column/libpkg-guide/
(referenced from sec 6.7.2 of Developer Reference)
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: conditional dependency?
Nikita V. Youshchenko wrote:
Hi
I maintain libetpan package, which build-depends on libcurl4-gnutls-dev.
Resulting library package dependency is calculated using ${shlib:Depends},
however libdev package dependency on libcurl4-gnutls-dev is manually
written in debian/control file. The build package dependency is valuable
since -lcurl is among 'libetpan-config --ldflags' output.
I've got a wishlist report (#467297), where reporter asks to add
alternative dependency libcurl3-gnutls-dev for better backporting support.
While it is easy for build-dependency (just use libcurl4-gnutls-dev |
libcurl3-gnutls-dev), I see a problem here with libdev package dependency.
It should depend not on libcurl4-gnutls-dev | libcurl3-gnutls-dev, but on
exact one that was actually used when building package.
In general alternative build dependencies are not recomended as we want
to have a predictable build process. The main thing when backporting is
changing build dependencies AFAICS. Normaly the intention is to change
as less as possible between the old version and the backported version's
environment unless necessary for new features AFAICT, so for someone who
is used to backport it should still be straight forward either way AFAICS.
Cheers
Luk
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: conditional dependency?
On Tue, Feb 26, 2008 at 12:11:05AM +0300, Nikita V. Youshchenko wrote: While it is easy for build-dependency (just use libcurl4-gnutls-dev | libcurl3-gnutls-dev), I see a problem here with libdev package dependency. It should depend not on libcurl4-gnutls-dev | libcurl3-gnutls-dev, but on exact one that was actually used when building package. How to handle this properly? Fix libetpan-config on Debian to not return libraries that are only related to static linking, and drop libcurl4-gnutls-dev to a Recommends? This looks against how librarieshave been packaged in the past. Which has been discussed many times on this mailing list. In particular, Debian Library Packaging guide [0] This is not a normative document, and is not governed by the procedures for Debian policy updates. Did something change recently? Maybe I missed something? There is nothing in policy that requires library -dev packages to depend on all the other libraries needed for static linking. It happens to be common practice, but that doesn't mean these couldn't be reduced to Recommends as long as dynamic linking continues to work correctly. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ [EMAIL PROTECTED] [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bits from the DPL: FTP assistants, marketing team, init scripts, elections
On Sun, 2008-02-24 at 19:48 +0100, martin f krafft wrote: also sprach Sam Hocevar [EMAIL PROTECTED] [2008.02.24.1316 +0100]: I also would like to spend some Debian money on a contest, similar to the FreeBSD logo contest [2], to create a friendly mascot for the Debian project (in a similar way to the Linux penguin or the GNU gnu) that we can use where the logo is not enough. More on this in a few days. In the free software zoo, the Debian Swirl sticks out like no other logo. Do we have to get a mascot? The same way Geppetto is fixing Pinocchio, Debian is always fixing Sid (The boy that break it's toys) to turn it into stable. Of course, Geppetto isn't a mascott... I can think of a spider, which always makes a perfect web, even if you break it. Also, the Beaver comes to my mind. Franklin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: ANNOUNCEMENT: debimg - debian-cd in Python
[ Reply-To: set to debian-cd list ] Hi Julian, On Mon, Feb 25, 2008 at 10:17:46PM +0100, Julian Andres Klode wrote: Dear Debian Developers (and other readers), debimg will be a free alternative to debian-cd, written in Python. I hope you're not meaning to imply that debian-cd itself is _not_ free...? snip overview Current status -- debimg can build complete disks, but can not split disks or build multi-arch images. It is not released yet, because the code needs some cleanup first. The next steps will be: disk splitting, multi-arch disks, source disks, architectures other than i386 and amd64, gpg signing, etc. Cool! Sounds like you've made a good start already. Be prepared for a lot more work to follow, though - there's a *lot* of work involved, possibly more than you realise. :-) -- Steve McIntyre, Cambridge, UK.[EMAIL PROTECTED] Because heaters aren't purple! -- Catherine Pitt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian Configuration Packaging System
On Mon, 25 Feb 2008, Frank K??ster wrote: Uh, you can dpkg-divert conffiles, but not generally configuration files, since many won't even be known to dpkg. I must admit I'm a bit sceptical about a proposal on configuration, written by someone who lets this important distinction slip by... No, I really meant configuration files. While our system certainly applies to all conffiles, it also applies to various other classes of files: 1) Those that are accidentally not marked as conffiles (e.g. /etc/adduser.conf). 2) Those that are initially created via a system like debconf but that preserve user changes, often because they support other configuration options than those in debconf (e.g. /etc/krb5.conf or /etc/ssh/sshd_config) [the dpkg-divert doesn't do anything here, but the system still works]. 3) Scripts that are not marked as conffiles but which cannot be configured in any way other than by modifying the script. I probably should have said this explicitly earlier, but our system is currently only an 80% solution, because it cannot override any package's configuration file handling system that does not preserve manual changes. It turns out that these are fairly rare, and can be handled with some annoyance (e.g. releasing a new version of our configuration package whenever a new release of such a package comes out, so that the configuration package wins). I would like to see it become a 100% solution, since I think support for easily creating configuration packages would be really valuable for a lot of organizations using Debian and Ubuntu. The primary difficulties are interacting nicely with systems like ucf and debconf; I don't think that it is possible to achieve 100% without some changes to Debian itself. Because of ucf's architecture, it would be easy to make ucf interact nicely with our system (and our system should perhaps use ucf itself, since it seems to be a strict improvement over the just marking things as conffiles). There are really two problems with debconf in our system. The first is that debconf asks questions which our configuration package system will override. Using 'DEBCONF_PRIORITY=critical apt-get install' limits them, but some packages we configure prompt for information even with critical DEBCONF_PRIORITY (is this a bug?). The second problem is that some packages override any manual changes to the relevant configuration file. Because the code to take action based on debconf selections in so decentralized, this second problem is relatively hard. For the second debconf problem, the easiest solution would be to add to our system support for pre-seeding the debconf database for package X and then running the configure script for package X. We have the tools to do this, and it would work, but it would lose a property of our system that I really like: support for uninstalling configuration packages. I would prefer to come up with a solution that does not lose this feature. I can think of several solutions preserving this feature that require changing every package that blindly overwrites user configuration on package upgrades to do some sort of check before doing so; I would love to hear ideas for mechanisms for achieving our goals (see http://debathena.mit.edu/config-packages/#philosophy) without having to change all such packages. Later on you wrote something about symlinks, do you use them, too? Here's one more complication: While I think that preserve local changes also includes the symlink-or-not state of a file and thus must be respected by maintainer scripts, I do not think that this is usually done. In particular, every configuration file handling that was first written for sarge (where sed -i wouldn't work) probably used tempfiles and mv, and I have not seen a single case where the script checked whether it was dealing with a symlink. To be precise, after installing a package that intends to configure /etc/ldap/ldap.conf, the system will be in the following configuration: $ ls -l /etc/ldap/ldap.conf* [irrelevant stat information removed] /etc/ldap/ldap.conf - ldap.conf.debathena /etc/ldap/ldap.conf.debathena /etc/ldap/ldap.conf.debathena-orig $ /usr/sbin/dpkg-divert --list | grep ldap diversion of /etc/ldap/ldap.conf to /etc/ldap/ldap.conf.debathena-orig by debathena-ldap-config So, yes, our system uses both symlinks and dpkg-divert. Simply placing files at /etc/ldap/ldap.conf (rather than using a symlink) doesn't work because it would require running dpkg-divert at preinst rather than postinst, which results in needing to pre-depend the packages whose configuration one is changing, and lots of other problems. It's not just ucf, it's also perfectly possible that a maintainer script edits a configuration file, e.g. after debconf prompting, in order to take over user changes from a related package's configuration file, or similar. How do you deal with that? Indeed, there's almost nothing
Re: Mass bug filing: perl 5.10 and the remove empty /usr/lib/perl5 dir bug
On Mon, Feb 18, 2008 at 10:03:59PM +0200, Niko Tyni wrote:
[crossposted to debian-{devel,[EMAIL PROTECTED];
Mail-Followup-To: [EMAIL PROTECTED] ]
This still applies.
Summary: around 400 *-perl packages have a debian/rules bug that
makes them FTBFS with perl 5.10, currently in experimental.
The suggested fix is simple: use a conditional like
[ ! -d $(TMP)/usr/lib/perl5 ] || rmdir --ignore-fail-on-non-empty
--parents --verbose $(TMP)/usr/lib/perl5
which is what the current dh-make-perl templates recommend.
Bug #465783 discusses whether the ExtUtils::Install behaviour should be
reverted for Lenny or not, but these are definitely bugs in any case.
I ran a few greps on debian/rules of the source packages of all the
binary packages matching '-perl' in unstable as of Feb 14th. Results: 398
arch:all and 38 arch:any packages apparently do an unconditional rmdir
for the empty directory. I have tried my best to avoid false positives,
but I'd be delighted if there's a mistake here.
It would be nice to verify these results with a real mass rebuild with
Perl 5.10 from experimental. I'll work on that, but there are going to
be a few bootstrapping problems, so I'm attaching the dd-list now based
on the grep results.
I have now rebuilt all the *-perl packages with Perl 5.10.0, and 391
Architecture: all and 24 Architecture:any packages failed to build due
to this issue. This includes 18 new packages, and 37 are gone either
because they have been fixed since or because they failed to build in
a different way. Bugs have been filed for the latter case.
As I've been encouraged by Don Armstrong and Raphaël Hertzog, I intend
to mass file bugs on these tomorrow night at severity 'important' and
usertag [EMAIL PROTECTED] / perl-5.10-ftbfs-rmdir.
I'm attaching the updated dd-list for the 212 Architecture:all packages
not maintained by the Debian Perl Group. The 179 packages maintained by
the Debian Perl Group have still been excluded from the list, but I do
intend to file those as well.
Cheers,
--
Niko Tyni [EMAIL PROTECTED]
Krzysztof Krzyzaniak (eloy) [EMAIL PROTECTED]
libcatalyst-model-cdbi-perl (U)
libcatalyst-plugin-session-fastmmap-perl (U)
libcatalyst-view-tt-perl (U)
libclass-c3-componentised-perl (U)
libclass-dbi-fromform-perl (U)
libemail-valid-loose-perl
libfile-copy-recursive-perl (U)
libfile-modified-perl (U)
libhttp-body-perl (U)
libhttp-request-ascgi-perl (U)
liburi-query-perl (U)
Michael Ablassmeier [EMAIL PROTECTED]
libmp4-info-perl
Pierre-Matthieu Alamy [EMAIL PROTECTED]
libcrypt-des-ede3-perl
libdata-buffer-perl
Nacho Barrientos Arias [EMAIL PROTECTED]
libtest-cmd-perl
Don Armstrong [EMAIL PROTECTED]
perltidy
Ian Beckwith [EMAIL PROTECTED]
libmp3-tag-perl
libwww-opensearch-perl
Hilko Bengen [EMAIL PROTECTED]
liblwpx-paranoidagent-perl
libmail-milter-perl
Bastian Blank [EMAIL PROTECTED]
libalgorithm-annotate-perl
libdata-hierarchy-perl
libextutils-autoinstall-perl
libfile-temp-perl
libfile-type-perl
libio-digest-perl
liblocale-maketext-simple-perl
libperlio-via-dynamic-perl
libperlio-via-symlink-perl
libregexp-shellish-perl
libsvn-mirror-perl
libsvn-simple-perl
Marc 'HE' Brockschmidt [EMAIL PROTECTED]
libexporter-tidy-perl
libextutils-pkgconfig-perl
libgtk2-ex-podviewer-perl
libx11-freedesktop-desktopentry-perl
James Bromberger [EMAIL PROTECTED]
libclass-accessor-chained-perl
libfile-chdir-perl
libmodule-depends-perl
libwww-indexparser-perl
Itamar Almeida de Carvalho [EMAIL PROTECTED]
libxml-dt-perl
Francesco Cecconi [EMAIL PROTECTED]
libconfig-general-perl
libemail-find-perl
libhtml-fromtext-perl
Tzafrir Cohen [EMAIL PROTECTED]
libasterisk-agi-perl (U)
Marco d'Itri [EMAIL PROTECTED]
libnet-whois-ripe-perl
Debian Catalyst Maintainers [EMAIL PROTECTED]
libcatalyst-model-cdbi-perl
libcatalyst-plugin-session-fastmmap-perl
libcatalyst-view-tt-perl
libclass-c3-componentised-perl
libclass-dbi-fromform-perl
libfile-copy-recursive-perl
libfile-modified-perl
libhttp-body-perl
libhttp-request-ascgi-perl
liburi-query-perl
Debian VoIP Team [EMAIL PROTECTED]
libasterisk-agi-perl
Sebastien Delafond [EMAIL PROTECTED]
libnet-socks-perl
Yann Dirson [EMAIL PROTECTED]
deps
Florian Ernst [EMAIL PROTECTED]
libhtml-tableextract-perl
Gerfried Fuchs [EMAIL PROTECTED]
libdbix-abstract-perl
libnetserver-generic-perl
David Moreno Garza [EMAIL PROTECTED]
libperl6-say-perl
libxml-treepp-perl
Jonas Genannt [EMAIL PROTECTED]
libcrypt-hcesha-perl
libfile-flat-perl
libfile-homedir-perl
libjavascript-rpc-perl
libparams-util-perl
libpod-tests-perl
libprefork-perl
libtest-classapi-perl
libtest-inline-perl
Arne Goetje [EMAIL PROTECTED]
libsnmp-multi-perl
Stephen Gran [EMAIL PROTECTED]
libdate-convert-perl
Debian QA Group [EMAIL PROTECTED]
libcvs-perl
Re: conditional dependency?
On Mon, Feb 25, 2008 at 11:48:21PM +0300, Nikita V. Youshchenko wrote: While it is easy for build-dependency (just use libcurl4-gnutls-dev | libcurl3-gnutls-dev), I see a problem here with libdev package dependency. It should depend not on libcurl4-gnutls-dev | libcurl3-gnutls-dev, but on exact one that was actually used when building package. How to handle this properly? Just trim -lcurl from libetpan-config's output and remove the dependency altogether. Obviously, don't do this if libetpan's reverse deps *need* to build with -lcurl (which is unlikely) And what if somebody will try to link statically? Playing devil's advocate: Why would we want to support static linking, when dynamic linking works perfectly well? Although not very probably, until now Debian used to support static linking (libdev packages provide .a files, and depend on libdev packages that provide dependent .a files). I stopped providing static libraries in all my library packages quite a while back. No one used them, and they were just needless bloat. I can't say I would be upset if we dropped all the static libraries from the entire archive--is there actually a real world requirement for them in 2008? Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ `-GPG Public Key: 0x25BFB848 Please GPG sign your mail. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#467502: ITP: xotcl -- Extended Object Tcl (XOTcl) is an object-oriented scripting language based on Tcl
Package: wnpp Severity: wishlist Owner: Stefan Sobernig [EMAIL PROTECTED] * Package name: xotcl Version : 1.6.0+ Upstream Author : Gustaf Neumann [EMAIL PROTECTED], Uwe Zdun [EMAIL PROTECTED] * URL : http://www.xotcl.org/ * License : BSD Programming Lang: Tcl Description : Extended Object Tcl (XOTcl) is an object-oriented scripting language based on Tcl Extended Object Tcl (for short: XOTcl, pronounced exotickle) is an object-oriented scripting language based on Tcl. It was originally designed for providing language support for design patterns and provides novel constructs such as filters or transitive mixin classes. The language is designed for empowering rather than constraining system developers. The basic object model is highly influenced by CLOS. Learn more at http://www.xotcl.org. -- System Information: Debian Release: 4.0 APT prefers unstable APT policy: (500, 'unstable'), (500, 'stable') Architecture: i386 (i686) Kernel: Linux 2.6.18-5-686 (SMP w/1 CPU core) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: conditional dependency?
Roger Leigh [EMAIL PROTECTED] writes: I stopped providing static libraries in all my library packages quite a while back. No one used them, and they were just needless bloat. I can't say I would be upset if we dropped all the static libraries from the entire archive--is there actually a real world requirement for them in 2008? MIT Kerberos upstream has dropped support for static linking because of their new plugin infrastructure, and while they hope to reintroduce it by popular demand at some point, it's not a high priority. About the only useful purpose for static linking is when distributing client binaries to many systems where one can't use the native package manager and hence can't use real package dependencies. It lets you limit the amount of stuff that the person has to install. I've run into a few cases like that, but usually the real solution is to fix the underlying issues (often political) preventing the use of real packages with package management. It's more of an issue on systems like Solaris that don't have useful package managers. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: How to cope with patches sanely
On Mon, Feb 25, 2008 at 03:56:49AM -0600, Manoj Srivastava wrote: No, it does not. If branch A has pi = 2.34567; and branch B has pi = 3.14159; No matter how much quilting you do you cannot reconcile the fundamental conflict in the final. Either pi is 3.14159; or it is not; and if branch A requires pi not to be that value, and branch B requires pi to be that value, quilt can't make C be quantum like and have the value be both. Feature branches don't magically allow you to avoid merge conflicts either, so this is a red herring. Once you've resolved the conflict, then it becomes just another change. This change can become a diff in a stack of diffs. - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: conditional dependency?
On Mon, Feb 25, 2008 at 09:53:37PM +0100, Julien Cristau wrote: On Mon, Feb 25, 2008 at 23:48:21 +0300, Nikita V. Youshchenko wrote: Although not very probably, until now Debian used to support static linking (libdev packages provide .a files, and depend on libdev packages that provide dependent .a files). That's not true, afaik. If you're linking statically, you have to figure out dependencies on your own. Conventionally, library -dev packages do depend on other -dev packages that they require for static linking; and certainly, tools like pkg-config and libtool (and other home-grown foo-config scripts) tend to encourage this behavior. Nowadays, with a proper .pc file I would argue that this could be reduced to a Recommends. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ [EMAIL PROTECTED] [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted pj 0.0~20080211-1 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Sat, 23 Feb 2008 22:59:04 +0100 Source: pj Binary: libpj-java Architecture: source all Version: 0.0~20080211-1 Distribution: unstable Urgency: low Maintainer: Debian Java Maintainers [EMAIL PROTECTED] Changed-By: Manuel Prinz [EMAIL PROTECTED] Description: libpj-java - The Parallel Java Library Changes: pj (0.0~20080211-1) unstable; urgency=low . * New upstream release. Files: a347bc5a54f7d4641989b59e543f6b33 751 contrib/libs extra pj_0.0~20080211-1.dsc 0b9d9288d5ac49c78bc91027bfcbcd44 890069 contrib/libs extra pj_0.0~20080211.orig.tar.gz 9e722fe4e35cd74a0bba9b4c0588d2ad 3487 contrib/libs extra pj_0.0~20080211-1.diff.gz 9b907aed54c2ec3a350df3f0f6134e47 825858 contrib/libs extra libpj-java_0.0~20080211-1_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHwnEtWSOgCCdjSDsRAoBmAJ9KQuzFtA6rUzWDtF3jpbxIjPPVfACcD9Mt jjyGsWHI3s8HigPlTwSoRRA= =SR85 -END PGP SIGNATURE- Accepted: libpj-java_0.0~20080211-1_all.deb to pool/contrib/p/pj/libpj-java_0.0~20080211-1_all.deb pj_0.0~20080211-1.diff.gz to pool/contrib/p/pj/pj_0.0~20080211-1.diff.gz pj_0.0~20080211-1.dsc to pool/contrib/p/pj/pj_0.0~20080211-1.dsc pj_0.0~20080211.orig.tar.gz to pool/contrib/p/pj/pj_0.0~20080211.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted libclone-perl 0.28-1 (source amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Mon, 25 Feb 2008 01:18:41 +0100 Source: libclone-perl Binary: libclone-perl Architecture: source amd64 Version: 0.28-1 Distribution: unstable Urgency: low Maintainer: Debian Perl Group [EMAIL PROTECTED] Changed-By: gregor herrmann [EMAIL PROTECTED] Description: libclone-perl - recursively copy Perl datatypes Closes: 329514 463099 Changes: libclone-perl (0.28-1) unstable; urgency=low . * Take over for the Debian Perl Group with former maintainer's permission (cf. #463099). * debian/control: Added: Vcs-Svn field (source stanza); Vcs-Browser field (source stanza); Homepage field (source stanza). Changed: Maintainer set to Debian Perl Group pkg-perl- [EMAIL PROTECTED] (was: Bastian Blank [EMAIL PROTECTED]). Add /me to Uploaders. * debian/watch: use dist-based URL. * New upstream release (closes: #329514), builds also with Perl 5.10 (closes: #463099). * Set debhelper compatibility level to 6. * Set Standards-Version to 3.7.3 (no changes). * debian/rules: - delete /usr/share/perl5 only if it exists - don't ignore errors of make distclean - move dh_clean before make distclean and use it for removing stamp files - create install-stamp target - remove commented out or unused dh_* calls - move actual build and tests to build-stamp target * debian/copyright: - add upstream source location - add additional copyright holders - add copyright information for the packaging Files: 6fe750227e8d0b58a2c92f1dcc63dd08 860 perl optional libclone-perl_0.28-1.dsc 16186d984e358ab3ca069d00c81b7e5c 11274 perl optional libclone-perl_0.28.orig.tar.gz 5c858a1cb40d62a43516b7e40e0ba799 2434 perl optional libclone-perl_0.28-1.diff.gz 61cfdeed0669c0e2828035f731594e86 12772 perl optional libclone-perl_0.28-1_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHwoXtiyizGWoHLTkRAgYPAKC55I5Xx9ntQL30EkgtD7bDDRAPHQCfZgui TNSq9c+lX+rRaOUgo8vxuyA= =aBUR -END PGP SIGNATURE- Accepted: libclone-perl_0.28-1.diff.gz to pool/main/libc/libclone-perl/libclone-perl_0.28-1.diff.gz libclone-perl_0.28-1.dsc to pool/main/libc/libclone-perl/libclone-perl_0.28-1.dsc libclone-perl_0.28-1_amd64.deb to pool/main/libc/libclone-perl/libclone-perl_0.28-1_amd64.deb libclone-perl_0.28.orig.tar.gz to pool/main/libc/libclone-perl/libclone-perl_0.28.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted dirdiff 2.1-2 (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Mon, 25 Feb 2008 02:17:02 -0600 Source: dirdiff Binary: dirdiff Architecture: source i386 Version: 2.1-2 Distribution: unstable Urgency: low Maintainer: Steve M. Robbins [EMAIL PROTECTED] Changed-By: Steve M. Robbins [EMAIL PROTECTED] Description: dirdiff- Display and merge changes between two directory trees Closes: 466034 Changes: dirdiff (2.1-2) unstable; urgency=low . * debian/patches/funky-chars.patch: New. Take care to quote filenames (thanks, kostix). Closes: #466034. . * debian/rules: Use quilt to manage patches. Put DH_COMPAT level into debian/compat; switch from level 3 to level 5. Don't ignore errors in clean target (remove lintian warning). . * debian/control: Depend on quilt. Update debhelper dependency to version 5. Set Standards-Version to 3.7.3 (no changes). Add Homepage. Remove period from end of short description (to remove lintian warning). . * Makefile: Revert to upstream 2.1. * debian/patches/tcl-version.patch: New. Patch to Makefile that uses /usr/include/tcl8.4 instead of .../8.3. * debian/patches/shared-object.patch: New. Patch to Makefile to build shared object using -fPIC, soname libfilecmp.so.0.0, and link against -ltcl8.4. Files: 5e6c29abc717c38d92c0fcca91eb54d7 609 utils optional dirdiff_2.1-2.dsc 99f6b7f3f57d76444acf66305c225164 5877 utils optional dirdiff_2.1-2.diff.gz 599de5e861c27cfb13c797e5f3a77b2b 41792 utils optional dirdiff_2.1-2_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHwnsW0i2bPSHbMcURAgiLAJ9p3FfPSbcthuIiwqMezlvEz0xEWACcD05E 0qy/gW/4wkRYkyPnJEHInJo= =7DNo -END PGP SIGNATURE- Accepted: dirdiff_2.1-2.diff.gz to pool/main/d/dirdiff/dirdiff_2.1-2.diff.gz dirdiff_2.1-2.dsc to pool/main/d/dirdiff/dirdiff_2.1-2.dsc dirdiff_2.1-2_i386.deb to pool/main/d/dirdiff/dirdiff_2.1-2_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted lua-markdown 0.30-1 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Mon, 25 Feb 2008 09:18:13 +0100 Source: lua-markdown Binary: liblua5.1-markdown0 Architecture: source all Version: 0.30-1 Distribution: unstable Urgency: low Maintainer: Enrico Tassi [EMAIL PROTECTED] Changed-By: Enrico Tassi [EMAIL PROTECTED] Description: liblua5.1-markdown0 - A pure lua5.1 implementation of the Markdown text-to-html markup Changes: lua-markdown (0.30-1) unstable; urgency=low . * new upstream release Files: 6a07643ec546f80e364565c329400e36 825 interpreters optional lua-markdown_0.30-1.dsc 1d23a14606da7f779b7b15349252dc36 33695 interpreters optional lua-markdown_0.30.orig.tar.gz 177ee53f6a11b6607c8b4790d532f497 2502 interpreters optional lua-markdown_0.30-1.diff.gz 84ee426a6f441d1dc3178a8150d1ad8a 17036 interpreters optional liblua5.1-markdown0_0.30-1_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHwnqy7kkcPgEj8vIRAqYFAJ9ER5zPl+J0OBivae+hlTPcGBGlWACgmBvY l4IBjYfpu7+d9qJ7H29poxU= =zD6d -END PGP SIGNATURE- Accepted: liblua5.1-markdown0_0.30-1_all.deb to pool/main/l/lua-markdown/liblua5.1-markdown0_0.30-1_all.deb lua-markdown_0.30-1.diff.gz to pool/main/l/lua-markdown/lua-markdown_0.30-1.diff.gz lua-markdown_0.30-1.dsc to pool/main/l/lua-markdown/lua-markdown_0.30-1.dsc lua-markdown_0.30.orig.tar.gz to pool/main/l/lua-markdown/lua-markdown_0.30.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted cmigrep 1.4-4 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Mon, 25 Feb 2008 09:21:44 +0100 Source: cmigrep Binary: cmigrep Architecture: source all Version: 1.4-4 Distribution: unstable Urgency: low Maintainer: Debian OCaml Maintainers [EMAIL PROTECTED] Changed-By: Ralf Treinen [EMAIL PROTECTED] Description: cmigrep- search in OCaml compiled interface files Closes: 448148 Changes: cmigrep (1.4-4) unstable; urgency=low . [ Stefano Zacchiroli ] * fix vcs-svn field to point just above the debian/ dir . [ Ralf Treinen ] * Rebuild with ocaml 3.10.1 * Standards-Version 3.7.3 (no change) * Fix capitalization of OCaml in short package description * Do not use .UR macro in manpage * Do not install emacs mode any longer: compilation errors, and seems not realy useful (closes: Bug#448148). Files: b90dee51d7331be48ae21957ce4a2f07 1040 devel extra cmigrep_1.4-4.dsc 37668636e839e4c40a52795bf77a2b9a 4054 devel extra cmigrep_1.4-4.diff.gz 0f8548dde671a4525f9cabc413bb547e 181138 devel extra cmigrep_1.4-4_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHwnuDtzWmSeC6BMERAv66AKD8cChX6OWpJ1vXrm0jRrGwQPiWrACgzLa8 K1sZy73Un+68uNlKAOyFyqs= =Pibs -END PGP SIGNATURE- Accepted: cmigrep_1.4-4.diff.gz to pool/main/c/cmigrep/cmigrep_1.4-4.diff.gz cmigrep_1.4-4.dsc to pool/main/c/cmigrep/cmigrep_1.4-4.dsc cmigrep_1.4-4_all.deb to pool/main/c/cmigrep/cmigrep_1.4-4_all.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted boinc 5.10.42-1 (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Mon, 25 Feb 2008 00:53:20 +0100 Source: boinc Binary: boinc-client boinc-manager boinc-dev boinc-dbg Architecture: source i386 Version: 5.10.42-1 Distribution: unstable Urgency: low Maintainer: Debian BOINC Maintainers [EMAIL PROTECTED] Changed-By: Frank S. Thomas [EMAIL PROTECTED] Description: boinc-client - core client for the BOINC distributed computing infrastructure boinc-dbg - debugging symbols for BOINC binaries boinc-dev - development files to build applications for BOINC projects boinc-manager - GUI to control and monitor the BOINC core client Closes: 461630 Changes: boinc (5.10.42-1) unstable; urgency=low . [ Frank S. Thomas ] * New upstream release. * debian/rules: Make the scripts /usr/share/bug/boinc-client/script and /usr/share/doc/boinc-manager/examples/run-boincmgr executable because they have a shebang. Thanks Lintian for noticing this. * debian/patches/: Updated 101_fix_memory_detection_on_kfreebsd.patch for the new release. * debian/watch: Only check for versions with an even minor version number. Versions with an odd minor version number are test releases which are not intended for a wider audience. * Reverted the debhelper compat level bump. It was just unnecessary (boinc does not need V6) and it would have made backporting harder. * Merged the workaround from Ubuntu's 5.10.30-5ubuntu3 for Linux's new CFS with the following changes: - Renamed debian/extra/udev-usr_share to debian/extra/udev-cpu_share because this name seems to be more appropriate since this script changes the boinc user's cpu_share. - Install udev-cpu_share into /usr/share/boinc-client instead of /usr/lib/boinc-client since it is an architecture-independent shell script. - Use lowercase variables in the init script because UID is set by bash and it complains when trying to overwrite it. Thanks to Daniel Hahler [EMAIL PROTECTED] for investigating this issue and the patch. (closes: #461630) . boinc (5.10.30-5ubuntu3) hardy; urgency=low . * Install /usr/lib/boinc-client/udev-usr_share with correct perms (executable), so that it gets called by udevd. . boinc (5.10.30-5ubuntu2) hardy; urgency=low . * Revert changes from ubuntu1 and instead use the uevent udev interface to assign the lowest possible cpu_share to the boinc user. This is still considered to be a workaround. - Add debian/boinc-client.udev - debian/rules: call dh_installudev - Add debian/extra/udev-usr_share, which gets run by udevd - Drop debian/patches/ubuntu_temp_cfs_fix.patch * debian/boinc-client.init: Display cpu_share info for status action . boinc (5.10.30-5ubuntu1) hardy; urgency=low . * debian/patches/ubuntu_temp_cfs_fix.patch: Temporary workaround for the new CFS Linux scheduler, by adjusting the boinc user's cpu_share to the minimum (2) in the init script (LP: #177713) * Modify Maintainer value to match the DebianMaintainerField specification. Files: 4d2d3caf0a54ff24201425455fc68316 1249 net optional boinc_5.10.42-1.dsc fe0bc798e0b7678c9e8a65d779debe0a 9608152 net optional boinc_5.10.42.orig.tar.gz 33523b854167b159774e33b7fda8177b 55145 net optional boinc_5.10.42-1.diff.gz 3d741042fcc7abc3ac1a631b6812761c 345772 net optional boinc-client_5.10.42-1_i386.deb 52cdc835e6a2ecb8ba7ed5a9a657790d 1741902 x11 optional boinc-manager_5.10.42-1_i386.deb 5c5a8bf263bec2b324f3622fa917afb6 390210 devel optional boinc-dev_5.10.42-1_i386.deb 68f075280abca3971ba8249664f0b6a0 7068110 devel extra boinc-dbg_5.10.42-1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHwnEmft6HNdxCZCkRAmEWAJ9OgIjTKB3q8oo5C0HrKqVYilvKpwCfY0Jb 8hjrR0P7AgOa9k520nWOVj8= =sGPi -END PGP SIGNATURE- Accepted: boinc-client_5.10.42-1_i386.deb to pool/main/b/boinc/boinc-client_5.10.42-1_i386.deb boinc-dbg_5.10.42-1_i386.deb to pool/main/b/boinc/boinc-dbg_5.10.42-1_i386.deb boinc-dev_5.10.42-1_i386.deb to pool/main/b/boinc/boinc-dev_5.10.42-1_i386.deb boinc-manager_5.10.42-1_i386.deb to pool/main/b/boinc/boinc-manager_5.10.42-1_i386.deb boinc_5.10.42-1.diff.gz to pool/main/b/boinc/boinc_5.10.42-1.diff.gz boinc_5.10.42-1.dsc to pool/main/b/boinc/boinc_5.10.42-1.dsc boinc_5.10.42.orig.tar.gz to pool/main/b/boinc/boinc_5.10.42.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted libclass-methodmaker-perl 2.10-1 (source amd64)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Format: 1.7
Date: Mon, 25 Feb 2008 11:21:41 +0200
Source: libclass-methodmaker-perl
Binary: libclass-methodmaker-perl
Architecture: source amd64
Version: 2.10-1
Distribution: unstable
Urgency: low
Maintainer: Debian Perl Group [EMAIL PROTECTED]
Changed-By: Niko Tyni [EMAIL PROTECTED]
Description:
libclass-methodmaker-perl - perl module for creating generic methods
Closes: 463090 463093
Changes:
libclass-methodmaker-perl (2.10-1) unstable; urgency=low
.
[ gregor herrmann ]
* Take over for the Debian Perl Group with maintainer's permission
(cf. #463093).
* Add debian/watch.
* New upstream release; this is the unauthorized CPAN release from
http://search.cpan.org/~schwigon/Class-MethodMaker-2.10/ -- necessary to
fix the FBTFS with Perl 5.10 (closes: #463093). Add the author-style URL
for these releases to debian/watch.
* debian/control:
- add Vcs-Svn field (source stanza); Vcs-Browser field (source stanza);
Homepage field (source stanza)
- change Maintainer to Debian Perl Group pkg-perl-maintainers@
lists.alioth.debian.org (was: Peter Palfrader [EMAIL PROTECTED])
- depend on ${perl:Depends} and ${shlibs:Depends} (closes: #463090)
- add libipc-run-perl to Build-Depends (used in tests)
- add /me to Uploaders
* debian/rules:
- rewrite from scratch from dh-make-perl's template
- install TODO from debian/rules, don't install README anymore, remove
debian/docs accordingly
- install examples/*
* Set Standards-Version to 3.7.3 (no changes).
* Set debhelper compatibility level to 6; add debian/compat.
* Remove debian/lintian.override.
* Revert Build.PL to the pristine version (was patched in earlier
releases). (We still use Makefile.PL because building with Build.PL
fails.)
* Add patch class_methodmaker_constants_whatis.patch (creates a missing
whatis entry for a manpage); add quilt framework.
* debian/copyright: add current upstream source location and maintainer,
change to new format.
.
[ Niko Tyni ]
* Build-dependency version changes:
+ debhelper (= 6), not ( 6)
+ s/perl5/perl/, perl5 is provided by perl
+ the quilt in oldstable doesn't have quilt.make, we need (= 0.40)
* Add myself to Uploaders.
Files:
3090f80c73b2979ca3cb146377ca5472 995 perl optional
libclass-methodmaker-perl_2.10-1.dsc
97181580315dd9776eafae67827c909f 89286 perl optional
libclass-methodmaker-perl_2.10.orig.tar.gz
b307f0941269c55fdc9044f0396bdb46 4247 perl optional
libclass-methodmaker-perl_2.10-1.diff.gz
7d03ff4374ace35125e04da9a6aef39c 495344 perl optional
libclass-methodmaker-perl_2.10-1_amd64.deb
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
iD8DBQFHwoqZiyizGWoHLTkRAmGaAJ91wpRA7BcvxNW2GzAQ0qjBjJVZ1gCgo6/M
WSEMDWLbEiK75QdgO9OBtmw=
=uNKe
-END PGP SIGNATURE-
Accepted:
libclass-methodmaker-perl_2.10-1.diff.gz
to
pool/main/libc/libclass-methodmaker-perl/libclass-methodmaker-perl_2.10-1.diff.gz
libclass-methodmaker-perl_2.10-1.dsc
to
pool/main/libc/libclass-methodmaker-perl/libclass-methodmaker-perl_2.10-1.dsc
libclass-methodmaker-perl_2.10-1_amd64.deb
to
pool/main/libc/libclass-methodmaker-perl/libclass-methodmaker-perl_2.10-1_amd64.deb
libclass-methodmaker-perl_2.10.orig.tar.gz
to
pool/main/libc/libclass-methodmaker-perl/libclass-methodmaker-perl_2.10.orig.tar.gz
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted cupsys 1.3.5-2 (source all i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Mon, 25 Feb 2008 11:13:15 +0100 Source: cupsys Binary: libcupsys2 libcupsimage2 cupsys cupsys-client libcupsys2-dev libcupsimage2-dev cupsys-bsd cupsys-common cupsys-dbg Architecture: source all i386 Version: 1.3.5-2 Distribution: unstable Urgency: low Maintainer: Debian CUPS Maintainers [EMAIL PROTECTED] Changed-By: Martin Pitt [EMAIL PROTECTED] Description: cupsys - Common UNIX Printing System(tm) - server cupsys-bsd - Common UNIX Printing System(tm) - BSD commands cupsys-client - Common UNIX Printing System(tm) - client programs (SysV) cupsys-common - Common UNIX Printing System(tm) - common files cupsys-dbg - Common UNIX Printing System(tm) - debugging symbols libcupsimage2 - Common UNIX Printing System(tm) - image libs libcupsimage2-dev - Common UNIX Printing System(tm) - image development files libcupsys2 - Common UNIX Printing System(tm) - libs libcupsys2-dev - Common UNIX Printing System(tm) - development files Closes: 457810 459662 461331 Changes: cupsys (1.3.5-2) unstable; urgency=low . [ Martin Pitt ] * debian/cupsys.init.d: Add Should-Start: avahi. (Closes: #459662) . [ Till Kamppeter ] * debian/patches/pdftops-cups-1.4.dpatch, debian/local/filters/pdftops: Replaced Helge Blischke's alternative pdftops wrapper by the pdftops of CUPS 1.4. The old pdftops wrapper did not work with the pdftops filter of Poppler, the new one works with the pdftops filters of both Poppler and XPDF (Closes: #457810; Ubuntu LP: #182379). * debian/patches/web-interface-breaks-default-auth-setting.dpatch: When modifying server settings with the CUPS web interface, the setting for the default authentication got overwritten with gibberish (Closes: #461331; CUPS STR #2703, Ubuntu LP: #188426). * debian/local/backends/dnssd: Updated dnssd to filter out IPv6 entries, as they clutter the lists of detected printers and make the network printer discovery process taking more time than needed. Applied also a bug fix and the possibility of querying one IP address by calling the dnssd backend with the IP as command line argument (like the snmp CUPS backend). Files: 029c15044c4aeaeddebc494d794534e2 1170 net optional cupsys_1.3.5-2.dsc fb8568dcd1e672483239e0ae34e0111a 109460 net optional cupsys_1.3.5-2.diff.gz 9f332572cfd2db045bc178849d7d5ce5 1125482 net optional cupsys-common_1.3.5-2_all.deb 5ca96f7036524b08272918e1e4650f7c 164700 libs optional libcupsys2_1.3.5-2_i386.deb 3161203e6c4112cd216e94ce75d2dce0 88470 libs optional libcupsimage2_1.3.5-2_i386.deb b6dba70d43f0973abd4be50997d8537d 2100246 net optional cupsys_1.3.5-2_i386.deb 5bf8cbf1a47418a1fb1bff2e58c6b919 87208 net optional cupsys-client_1.3.5-2_i386.deb 8f2f8aee454c6fcab4ae6342fa1255f9 141862 libdevel optional libcupsys2-dev_1.3.5-2_i386.deb 8c7bc8e4f6db8814d03810a0a2133caf 58138 libdevel optional libcupsimage2-dev_1.3.5-2_i386.deb d8c594e3fbe0b0b9179ad95b4bffa2ae 36574 net extra cupsys-bsd_1.3.5-2_i386.deb 571f4a52eb4c07956f04ab5416c3781d 1045896 libdevel extra cupsys-dbg_1.3.5-2_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHwpjcDecnbV4Fd/IRAuywAJ9AaWDSFUSJiCbIbraLdKbYZNKLIACgw4Y2 ra0+NPee34xh1+mVpJ5cFDI= =B8y8 -END PGP SIGNATURE- Accepted: cupsys-bsd_1.3.5-2_i386.deb to pool/main/c/cupsys/cupsys-bsd_1.3.5-2_i386.deb cupsys-client_1.3.5-2_i386.deb to pool/main/c/cupsys/cupsys-client_1.3.5-2_i386.deb cupsys-common_1.3.5-2_all.deb to pool/main/c/cupsys/cupsys-common_1.3.5-2_all.deb cupsys-dbg_1.3.5-2_i386.deb to pool/main/c/cupsys/cupsys-dbg_1.3.5-2_i386.deb cupsys_1.3.5-2.diff.gz to pool/main/c/cupsys/cupsys_1.3.5-2.diff.gz cupsys_1.3.5-2.dsc to pool/main/c/cupsys/cupsys_1.3.5-2.dsc cupsys_1.3.5-2_i386.deb to pool/main/c/cupsys/cupsys_1.3.5-2_i386.deb libcupsimage2-dev_1.3.5-2_i386.deb to pool/main/c/cupsys/libcupsimage2-dev_1.3.5-2_i386.deb libcupsimage2_1.3.5-2_i386.deb to pool/main/c/cupsys/libcupsimage2_1.3.5-2_i386.deb libcupsys2-dev_1.3.5-2_i386.deb to pool/main/c/cupsys/libcupsys2-dev_1.3.5-2_i386.deb libcupsys2_1.3.5-2_i386.deb to pool/main/c/cupsys/libcupsys2_1.3.5-2_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted gammu 1.18.91-1 (source i386 all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Mon, 25 Feb 2008 11:10:17 +0100 Source: gammu Binary: gammu libgammu-dev libgammu-common libgammu3 libgammu3-dbg Architecture: source i386 all Version: 1.18.91-1 Distribution: experimental Urgency: low Maintainer: Michal Čihař [EMAIL PROTECTED] Changed-By: Michal Čihař [EMAIL PROTECTED] Description: gammu - Mobile phone management utility libgammu-common - Mobile phone management library libgammu-dev - Header files for Gammu libgammu3 - Mobile phone management library libgammu3-dbg - Mobile phone management library - debugger symbols Closes: 465188 Changes: gammu (1.18.91-1) experimental; urgency=low . * New upstream version. * Move libgammu3-dbg to section libdevel (Closes: #465188). Files: 2b05597a3193b28bac33ff01f0d348cd 866 comm optional gammu_1.18.91-1.dsc c69b9c697eef7c0113962dd3d8d4c32b 1351535 comm optional gammu_1.18.91.orig.tar.gz 107326dab3918cc5a226bff9e17cc1f2 6040 comm optional gammu_1.18.91-1.diff.gz 81098529ffa9c2e853a7c1ad772ec16b 276332 comm optional gammu_1.18.91-1_i386.deb b1fdfc9d9db16bc2ac87d8f311b7fde4 167676 libdevel optional libgammu-dev_1.18.91-1_i386.deb 15bf8666cb8e4123282ee5137e8c80a4 144408 libs optional libgammu-common_1.18.91-1_all.deb 73f4741bf57626c8e84b4c1aa8f8a4d8 446450 libs optional libgammu3_1.18.91-1_i386.deb a5739d1b6a7a8ce7909675374dc54a8d 1082410 libdevel extra libgammu3-dbg_1.18.91-1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHwpZI3DVS6DbnVgQRAuQSAJ4925qlFDdXYTPquJH8OH+VbTzFxgCg4QM+ KqdLP+V63uN8jQ7yYvwqPag= =sS82 -END PGP SIGNATURE- Accepted: gammu_1.18.91-1.diff.gz to pool/main/g/gammu/gammu_1.18.91-1.diff.gz gammu_1.18.91-1.dsc to pool/main/g/gammu/gammu_1.18.91-1.dsc gammu_1.18.91-1_i386.deb to pool/main/g/gammu/gammu_1.18.91-1_i386.deb gammu_1.18.91.orig.tar.gz to pool/main/g/gammu/gammu_1.18.91.orig.tar.gz libgammu-common_1.18.91-1_all.deb to pool/main/g/gammu/libgammu-common_1.18.91-1_all.deb libgammu-dev_1.18.91-1_i386.deb to pool/main/g/gammu/libgammu-dev_1.18.91-1_i386.deb libgammu3-dbg_1.18.91-1_i386.deb to pool/main/g/gammu/libgammu3-dbg_1.18.91-1_i386.deb libgammu3_1.18.91-1_i386.deb to pool/main/g/gammu/libgammu3_1.18.91-1_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted groff 1.18.1.1-17 (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Mon, 25 Feb 2008 09:29:46 + Source: groff Binary: groff-base groff Architecture: source i386 Version: 1.18.1.1-17 Distribution: unstable Urgency: low Maintainer: Colin Watson [EMAIL PROTECTED] Changed-By: Colin Watson [EMAIL PROTECTED] Description: groff - GNU troff text-formatting system groff-base - GNU troff text-formatting system (base system components) Closes: 466614 Changes: groff (1.18.1.1-17) unstable; urgency=low . * Backport from upstream: - Make the mdoc .In macro parsed and callable. If not in the synopsis, represent the C header file enclosed in angle brackets (closes: #466614). Files: 09c31f2fe13f229f940ba39c76e7e564 777 text important groff_1.18.1.1-17.dsc bd6a16e6b602ff5f93422151eff1d195 132285 text important groff_1.18.1.1-17.diff.gz f11ce2a0709b1e2aa33745373f7374dd 844312 text important groff-base_1.18.1.1-17_i386.deb a253055a1ff6748362128ac073a4c8e4 1909908 text optional groff_1.18.1.1-17_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Colin Watson [EMAIL PROTECTED] -- Debian developer iD8DBQFHwpKu9t0zAhD6TNERAqgNAJ96L9tzgl3SSJuYEPEu0wlrWgDxxQCfdvvB 28PK9OElNATo6i4ZtUfGHrA= =PNxz -END PGP SIGNATURE- Accepted: groff-base_1.18.1.1-17_i386.deb to pool/main/g/groff/groff-base_1.18.1.1-17_i386.deb groff_1.18.1.1-17.diff.gz to pool/main/g/groff/groff_1.18.1.1-17.diff.gz groff_1.18.1.1-17.dsc to pool/main/g/groff/groff_1.18.1.1-17.dsc groff_1.18.1.1-17_i386.deb to pool/main/g/groff/groff_1.18.1.1-17_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted cfingerd 1.4.3-2 (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Mon, 25 Feb 2008 10:43:57 +0100 Source: cfingerd Binary: cfingerd Architecture: source i386 Version: 1.4.3-2 Distribution: unstable Urgency: low Maintainer: Martin Schulze [EMAIL PROTECTED] Changed-By: Martin Schulze [EMAIL PROTECTED] Description: cfingerd - configurable finger daemon Closes: 66440 380219 381119 414308 453963 Changes: cfingerd (1.4.3-2) unstable; urgency=low . * Partially imported NMU * Updated URLs in copyright file * Removed /usr/doc support code from postinst since the transition is completed * Updated debian/rules * Converted changelog to UTF-8 (closes: Bug#453963) * Applied patch by Cyril Brulebois to make GNU/kFreeBSD and GNU/Hurd act as GNU/Linux (closes: Bug#414308) * Remove deprecated tail syntax (closes: Bug#381119) * Fixed problem with removing double characters in search strings (closes: Bug#66440) * Adjusted addresses in Debian files (closes: Bug#380219) Files: 3972514e9184d364505aa581f3dbb585 529 net extra cfingerd_1.4.3-2.dsc 32cb4f27f08f0240c94f96af3d1ccf54 17314 net extra cfingerd_1.4.3-2.diff.gz 9bfc7dfcf0bff50f533ed351c4551abe 73516 net extra cfingerd_1.4.3-2_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHwo5lW5ql+IAeqTIRArDKAKCebJEQe71PlauCfqfz44ZeMWkrWwCgp1yp vyrgr0dH+r7KNAoDwN0Og1M= =0TbK -END PGP SIGNATURE- Accepted: cfingerd_1.4.3-2.diff.gz to pool/main/c/cfingerd/cfingerd_1.4.3-2.diff.gz cfingerd_1.4.3-2.dsc to pool/main/c/cfingerd/cfingerd_1.4.3-2.dsc cfingerd_1.4.3-2_i386.deb to pool/main/c/cfingerd/cfingerd_1.4.3-2_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted gst-fluendo-mp3 0.10.7.debian-1 (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Mon, 25 Feb 2008 11:49:03 +0100 Source: gst-fluendo-mp3 Binary: gstreamer0.10-fluendo-mp3 Architecture: source i386 Version: 0.10.7.debian-1 Distribution: unstable Urgency: low Maintainer: Maintainers of GStreamer packages [EMAIL PROTECTED] Changed-By: Sebastian Dröge [EMAIL PROTECTED] Description: gstreamer0.10-fluendo-mp3 - Fluendo mp3 decoder GStreamer plugin Changes: gst-fluendo-mp3 (0.10.7.debian-1) unstable; urgency=low . * New upstream release: + debian/patches/01_small-mp3-frames.patch: - Dropped, merged upstream. * debian/control: + Require gstreamer = 0.10.14. It's not explicitely required upstream but having it enables some more features. Files: b58a92821796b935c1cfadf9a712ac01 957 libs optional gst-fluendo-mp3_0.10.7.debian-1.dsc b269f433a3030e473d80f18c9bac5ca0 465490 libs optional gst-fluendo-mp3_0.10.7.debian.orig.tar.gz 4ca2e8d48d56f2d1d3f811fc5697bf21 4183 libs optional gst-fluendo-mp3_0.10.7.debian-1.diff.gz e7dcb69d8067e03cd6a5725f6973f3a9 95378 libs optional gstreamer0.10-fluendo-mp3_0.10.7.debian-1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHwqInBsBdh1vkHyERAg29AKCSgyVZ8x412rQazMCfeysSQ2MgVQCfUwSY 02bzxrnd/5sinMm/ET7JXjQ= =RuA2 -END PGP SIGNATURE- Accepted: gst-fluendo-mp3_0.10.7.debian-1.diff.gz to pool/main/g/gst-fluendo-mp3/gst-fluendo-mp3_0.10.7.debian-1.diff.gz gst-fluendo-mp3_0.10.7.debian-1.dsc to pool/main/g/gst-fluendo-mp3/gst-fluendo-mp3_0.10.7.debian-1.dsc gst-fluendo-mp3_0.10.7.debian.orig.tar.gz to pool/main/g/gst-fluendo-mp3/gst-fluendo-mp3_0.10.7.debian.orig.tar.gz gstreamer0.10-fluendo-mp3_0.10.7.debian-1_i386.deb to pool/main/g/gst-fluendo-mp3/gstreamer0.10-fluendo-mp3_0.10.7.debian-1_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted weka 3.5.7+tut1-1 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Sun, 24 Feb 2008 09:18:45 +0100 Source: weka Binary: weka weka-doc Architecture: source all Version: 3.5.7+tut1-1 Distribution: unstable Urgency: low Maintainer: Soeren Sonnenburg [EMAIL PROTECTED] Changed-By: Soeren Sonnenburg [EMAIL PROTECTED] Description: weka - Machine learning algorithms for data mining tasks weka-doc - Machine learning algorithms for data mining tasks Changes: weka (3.5.7+tut1-1) unstable; urgency=low . * Updated weka script to support calling other main classes, add jvm memory option and allow specific gui. * Update manpage for weka script, documenting the new options. * Fetch tutorial sources from public svn, generate them dynamically on build and include generated .pdfs in doc-base. Files: 24e481ecf7ae6e09e8b0a02d01d00e50 838 contrib/science optional weka_3.5.7+tut1-1.dsc 078d362a2f94b7d51c65214257515651 7472438 contrib/science optional weka_3.5.7+tut1.orig.tar.gz 42bbb94c740b4322baba38c27d6dec4a 5018 contrib/science optional weka_3.5.7+tut1-1.diff.gz 0e09780abf8db3cefe583000f90eca74 3945644 contrib/science optional weka_3.5.7+tut1-1_all.deb 6585bc3db118e7de6a50eed96f41dc50 4786598 contrib/doc optional weka-doc_3.5.7+tut1-1_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHwqFZfY3dicTPjsMRAjAiAJ9aLxmDJSCP6r+TXtaZaN1LTuqSkACeMXws 3VOM77NbGRL86WFPRO32dSQ= =Id/H -END PGP SIGNATURE- Accepted: weka-doc_3.5.7+tut1-1_all.deb to pool/contrib/w/weka/weka-doc_3.5.7+tut1-1_all.deb weka_3.5.7+tut1-1.diff.gz to pool/contrib/w/weka/weka_3.5.7+tut1-1.diff.gz weka_3.5.7+tut1-1.dsc to pool/contrib/w/weka/weka_3.5.7+tut1-1.dsc weka_3.5.7+tut1-1_all.deb to pool/contrib/w/weka/weka_3.5.7+tut1-1_all.deb weka_3.5.7+tut1.orig.tar.gz to pool/contrib/w/weka/weka_3.5.7+tut1.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted libepc 0.3.4-2 (source all i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Mon, 25 Feb 2008 10:34:30 +0100 Source: libepc Binary: libepc-1.0-1 libepc-ui-1.0-1 libepc-dev libepc-ui-dev libepc-doc Architecture: source all i386 Version: 0.3.4-2 Distribution: experimental Urgency: low Maintainer: Emilio Pozuelo Monfort [EMAIL PROTECTED] Changed-By: Emilio Pozuelo Monfort [EMAIL PROTECTED] Description: libepc-1.0-1 - The Easy Publish and Consume library - shared libraries libepc-dev - The Easy Publish and Consume library - development files libepc-doc - The Easy Publish and Consume library - documentation libepc-ui-1.0-1 - The Easy Publish and Consume library - shared widget libraries libepc-ui-dev - The Easy Publish and Consume library - widget development files Changes: libepc (0.3.4-2) experimental; urgency=low . [ Emilio Pozuelo Monfort ] * Upload to experimental. * Cleanup changelog of 0.3.4-1. * Build depend on libsoup2.4-dev, instead of libsoup2.2-dev. * Require libglib2.0-dev = 2.15.1 to get GIO support. This enables mimetype detection in libepc. * Bump shlibs to 0.3.4-2 as we build with MIME type support. * Rename 'api-break' to 'api-change' in debian/rules. . [ Loic Minier ] * Include check-dist.mk to prevent accidental upload to unstable. * Rename $(api-change) to $(SHLIBVER). * Tidy up libepc.* regexps. Files: c0e5ef0573ad38546b1520f41397b2af 1189 libs optional libepc_0.3.4-2.dsc 86b5fe835464026a97f526db87fe8705 3357 libs optional libepc_0.3.4-2.diff.gz 1edec66babc3e405dd9139c9e8442268 171792 doc optional libepc-doc_0.3.4-2_all.deb e1adddaab759a317f0ccdf01ac2e0acc 61778 libs optional libepc-1.0-1_0.3.4-2_i386.deb fc035d146a404199d125d30337345988 31246 libs optional libepc-ui-1.0-1_0.3.4-2_i386.deb 2870ac68e6a200317444676a13188a75 73552 libdevel optional libepc-dev_0.3.4-2_i386.deb 2ad95fda4d1741e95326a53b5b2fbf6f 31422 libdevel optional libepc-ui-dev_0.3.4-2_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHwqD04VUX8isJIMARAr9uAJ9ymjmDZOGGtjdisYqVl1v+gwhLdQCeJMHZ obnG6AganH4YQmciC7yyScw= =zpqM -END PGP SIGNATURE- Accepted: libepc-1.0-1_0.3.4-2_i386.deb to pool/main/libe/libepc/libepc-1.0-1_0.3.4-2_i386.deb libepc-dev_0.3.4-2_i386.deb to pool/main/libe/libepc/libepc-dev_0.3.4-2_i386.deb libepc-doc_0.3.4-2_all.deb to pool/main/libe/libepc/libepc-doc_0.3.4-2_all.deb libepc-ui-1.0-1_0.3.4-2_i386.deb to pool/main/libe/libepc/libepc-ui-1.0-1_0.3.4-2_i386.deb libepc-ui-dev_0.3.4-2_i386.deb to pool/main/libe/libepc/libepc-ui-dev_0.3.4-2_i386.deb libepc_0.3.4-2.diff.gz to pool/main/libe/libepc/libepc_0.3.4-2.diff.gz libepc_0.3.4-2.dsc to pool/main/libe/libepc/libepc_0.3.4-2.dsc -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted cdebootstrap 0.4.8 (source amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Mon, 25 Feb 2008 12:12:04 +0100 Source: cdebootstrap Binary: cdebootstrap cdebootstrap-static cdebootstrap-udeb Architecture: source amd64 Version: 0.4.8 Distribution: unstable Urgency: low Maintainer: Bastian Blank [EMAIL PROTECTED] Changed-By: Bastian Blank [EMAIL PROTECTED] Description: cdebootstrap - Bootstrap a Debian system cdebootstrap-static - Bootstrap a Debian system - static binary cdebootstrap-udeb - Bootstrap a Debian system - udeb (udeb) Changes: cdebootstrap (0.4.8) unstable; urgency=low . * Cleanup code. * Provide better message for execution failures. Files: ff4f650bc9762a2436b1b939946e2d73 637 admin optional cdebootstrap_0.4.8.dsc 0ae1c5fbfdcfb186a020b3ebff2df89b 141302 admin optional cdebootstrap_0.4.8.tar.gz 441937b21fc83ef87d8f17dc6230b52b 31800 admin optional cdebootstrap_0.4.8_amd64.deb 63f49bcd0c71f1c7448598df28ca3ccd 599624 admin optional cdebootstrap-static_0.4.8_amd64.deb 24d48b05511411358db1a084e73b533d 21150 debian-installer optional cdebootstrap-udeb_0.4.8_amd64.udeb Package-Type: udeb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iEYEARECAAYFAkfCotwACgkQxWtQqFixGB4q5gCgiLuILWwQtE+nWe6D5UqbSYpD wY4An2jkbkSagDuw7n4YC8Z0dVGL4qKL =YmCe -END PGP SIGNATURE- Accepted: cdebootstrap-static_0.4.8_amd64.deb to pool/main/c/cdebootstrap/cdebootstrap-static_0.4.8_amd64.deb cdebootstrap-udeb_0.4.8_amd64.udeb to pool/main/c/cdebootstrap/cdebootstrap-udeb_0.4.8_amd64.udeb cdebootstrap_0.4.8.dsc to pool/main/c/cdebootstrap/cdebootstrap_0.4.8.dsc cdebootstrap_0.4.8.tar.gz to pool/main/c/cdebootstrap/cdebootstrap_0.4.8.tar.gz cdebootstrap_0.4.8_amd64.deb to pool/main/c/cdebootstrap/cdebootstrap_0.4.8_amd64.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted libnet-z3950-perl 0.51-4 (source amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Mon, 25 Feb 2008 13:05:40 +0200 Source: libnet-z3950-perl Binary: libnet-z3950-perl Architecture: source amd64 Version: 0.51-4 Distribution: unstable Urgency: low Maintainer: Debian Perl Group [EMAIL PROTECTED] Changed-By: Niko Tyni [EMAIL PROTECTED] Description: libnet-z3950-perl - Perl interface to the Z39.50 information retrieval protocol Changes: libnet-z3950-perl (0.51-4) unstable; urgency=low . [ gregor herrmann ] * debian/control: Added: Vcs-Svn field (source stanza); Vcs-Browser field (source stanza); Homepage field (source stanza). Removed: XS- Vcs-Svn fields. * debian/watch: use dist-based URL. * debian/rules: delete /usr/share/perl5 only if it exists. . [ Niko Tyni ] * Switch to my @debian.org email address. * Fix inter-target dependencies in debian/rules * Remove commented invocations of debhelper utilities. * Upgrade to Standards-Version 3.7.3. No changes needed. * Remove a Debian change to doc/Makefile and work around the problem in debian/rules. * Update and reformat debian/copyright. * Remove the homepage information from the long description, it has a control field of its own now. Files: 78295c2963025fb7de947c00b1cb28e5 997 perl optional libnet-z3950-perl_0.51-4.dsc 7ac5f5692284c509e2d4c6dc57cabddb 3409 perl optional libnet-z3950-perl_0.51-4.diff.gz a58da2988c7cbd5654573c61dc81a086 141900 perl optional libnet-z3950-perl_0.51-4_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHwqUFiyizGWoHLTkRAs7RAKCZMkcWeU9Y/UBFlL++glOcdkLknQCgqrF4 ewegU65wRi6KDmqagpxDmQA= =9j2J -END PGP SIGNATURE- Accepted: libnet-z3950-perl_0.51-4.diff.gz to pool/main/libn/libnet-z3950-perl/libnet-z3950-perl_0.51-4.diff.gz libnet-z3950-perl_0.51-4.dsc to pool/main/libn/libnet-z3950-perl/libnet-z3950-perl_0.51-4.dsc libnet-z3950-perl_0.51-4_amd64.deb to pool/main/libn/libnet-z3950-perl/libnet-z3950-perl_0.51-4_amd64.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted omniorb4 4.1.1-3 (source all i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Sun, 24 Feb 2008 22:29:08 +0100 Source: omniorb4 Binary: omniorb4 omniorb4-idl omniorb4-nameserver omniorb4-doc libcos4-1 libcos4-1-dbg libcos4-dev libomniorb4-1 libomniorb4-1-dbg libomniorb4-dev libomnithread3c2 libomnithread3c2-dbg libomnithread3-dev omniidl4 Architecture: source all i386 Version: 4.1.1-3 Distribution: unstable Urgency: low Maintainer: Debian CORBA Team [EMAIL PROTECTED] Changed-By: Thomas Girard [EMAIL PROTECTED] Description: libcos4-1 - omniORB CORBA services stubs libcos4-1-dbg - omniORB CORBA services stubs debugging symbols libcos4-dev - omniORB CORBA services stubs development files libomniorb4-1 - omniORB core libraries libomniorb4-1-dbg - omniORB core libraries debugging symbols libomniorb4-dev - omniORB core libraries development files libomnithread3-dev - C++ threading library development files libomnithread3c2 - C++ threading library libomnithread3c2-dbg - C++ threading library debugging symbols omniidl4 - omniORB idl to C++ and Python compiler omniorb4 - omniORB naming service and IOR utilities omniorb4-doc - omniORB documentation omniorb4-idl - omniORB CORBA services idl files omniorb4-nameserver - omniORB naming service Closes: 460419 Changes: omniorb4 (4.1.1-3) unstable; urgency=low . * Build with g++-4.1 on arm to fix FTBFS. Closes: #460419. Files: 8a94c93cdaed7e5dde8d26b597d7dce5 1173 devel optional omniorb4_4.1.1-3.dsc 6568992974580a64d789fe73d3e9964f 11291 devel optional omniorb4_4.1.1-3.diff.gz 700ed8ef3140064a9133b0d392e1fa5f 63938 devel optional omniorb4-idl_4.1.1-3_all.deb 9a2701aba12bd9bac3b9539adbf6745b 227180 doc optional omniorb4-doc_4.1.1-3_all.deb 3d09068aacbc60b3f245881b551c46b4 61500 devel optional omniorb4_4.1.1-3_i386.deb ca1b4182f6438ee5f2ccce68c573c578 64140 devel optional omniorb4-nameserver_4.1.1-3_i386.deb 67a0819204b3df578b78132be1a3423c 1954246 libs optional libcos4-1_4.1.1-3_i386.deb 04c750e7c1725ba70f084c214b7ecb7b 4571940 libdevel extra libcos4-1-dbg_4.1.1-3_i386.deb c65df862b11f4a27722bd694e5b4db5a 2183636 libdevel optional libcos4-dev_4.1.1-3_i386.deb 37bfedcd4b498a1c359bf60a5ee1aa07 1416892 libs optional libomniorb4-1_4.1.1-3_i386.deb 8bd5b7688a6a918753bc81728a30e96b 4133458 libdevel extra libomniorb4-1-dbg_4.1.1-3_i386.deb ea22a7aef743c523b28a0a5ae8714056 1861762 libdevel optional libomniorb4-dev_4.1.1-3_i386.deb a715da5d239bff91c39c7e286a0dd6bb 32092 libs optional libomnithread3c2_4.1.1-3_i386.deb 2fef6b907c0e93ffad3fb063af5c9fab 37694 libdevel extra libomnithread3c2-dbg_4.1.1-3_i386.deb 584c849a55844e88f636cf9c0de8da29 38674 libdevel optional libomnithread3-dev_4.1.1-3_i386.deb cf40bbe5c3bf9e6670186718e9d9bdea 350326 devel optional omniidl4_4.1.1-3_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHwsmjz2LXlDjmjg4RAmsbAKCg7DZgnIdkTXaDuoRZ4PAV2HcBqQCfUnby Ll0ijwsOJdCKJsJs/Ww2BW4= =h/Ie -END PGP SIGNATURE- Accepted: libcos4-1-dbg_4.1.1-3_i386.deb to pool/main/o/omniorb4/libcos4-1-dbg_4.1.1-3_i386.deb libcos4-1_4.1.1-3_i386.deb to pool/main/o/omniorb4/libcos4-1_4.1.1-3_i386.deb libcos4-dev_4.1.1-3_i386.deb to pool/main/o/omniorb4/libcos4-dev_4.1.1-3_i386.deb libomniorb4-1-dbg_4.1.1-3_i386.deb to pool/main/o/omniorb4/libomniorb4-1-dbg_4.1.1-3_i386.deb libomniorb4-1_4.1.1-3_i386.deb to pool/main/o/omniorb4/libomniorb4-1_4.1.1-3_i386.deb libomniorb4-dev_4.1.1-3_i386.deb to pool/main/o/omniorb4/libomniorb4-dev_4.1.1-3_i386.deb libomnithread3-dev_4.1.1-3_i386.deb to pool/main/o/omniorb4/libomnithread3-dev_4.1.1-3_i386.deb libomnithread3c2-dbg_4.1.1-3_i386.deb to pool/main/o/omniorb4/libomnithread3c2-dbg_4.1.1-3_i386.deb libomnithread3c2_4.1.1-3_i386.deb to pool/main/o/omniorb4/libomnithread3c2_4.1.1-3_i386.deb omniidl4_4.1.1-3_i386.deb to pool/main/o/omniorb4/omniidl4_4.1.1-3_i386.deb omniorb4-doc_4.1.1-3_all.deb to pool/main/o/omniorb4/omniorb4-doc_4.1.1-3_all.deb omniorb4-idl_4.1.1-3_all.deb to pool/main/o/omniorb4/omniorb4-idl_4.1.1-3_all.deb omniorb4-nameserver_4.1.1-3_i386.deb to pool/main/o/omniorb4/omniorb4-nameserver_4.1.1-3_i386.deb omniorb4_4.1.1-3.diff.gz to pool/main/o/omniorb4/omniorb4_4.1.1-3.diff.gz omniorb4_4.1.1-3.dsc to pool/main/o/omniorb4/omniorb4_4.1.1-3.dsc omniorb4_4.1.1-3_i386.deb to pool/main/o/omniorb4/omniorb4_4.1.1-3_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted leafnode 1.11.7.rc1-4 (source amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Mon, 25 Feb 2008 11:50:31 + Source: leafnode Binary: leafnode Architecture: source amd64 Version: 1.11.7.rc1-4 Distribution: unstable Urgency: low Maintainer: Mark Brown [EMAIL PROTECTED] Changed-By: Mark Brown [EMAIL PROTECTED] Description: leafnode - NNTP server for small sites Closes: 466230 466358 466383 466466 466787 467044 467115 467416 Changes: leafnode (1.11.7.rc1-4) unstable; urgency=low . * Apply changes created by the Smith review project to Debconf templates# and the control file (closes: #466230). * Include updated Catalan Debconf translation kindly provided by Piarres Beobide [EMAIL PROTECTED] (closes: #466358). * Include updated Czech Debconf translation kindly provided by Martin Šín [EMAIL PROTECTED] (closes: #466383). * Include new Galician Debconf translation kindly provided by Jacobo Tarrio [EMAIL PROTECTED] (closes: #466466). * Include updated Portuguese Debconf translation kindly provided by Américo Monteiro [EMAIL PROTECTED] (closes: #466787). * Include updated German Debconf translation kindly provided by Jonas E. Huber [EMAIL PROTECTED] (closes: #467044). * Include updated Vietnamese Debconf translation kindly provided by Clytie Siddall [EMAIL PROTECTED] (closes: #467115). * Include updated Dutch Debconf translation kindly provided by Bart Cornelis [EMAIL PROTECTED] (closes: #467416). Files: 41e29915a0637782a3776a48f559fcd2 593 news extra leafnode_1.11.7.rc1-4.dsc 63d81503468821eb6795088545e75ab0 51179 news extra leafnode_1.11.7.rc1-4.diff.gz c4670e136bbe474e797a4a91510200ba 340446 news extra leafnode_1.11.7.rc1-4_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHwq3YJ2Vo11xhU60RAt74AKC5OtlJtSEYNLEmx+puMymBJezr3wCfbj2o N+oZPa92fQJhU7LXwQYFQZI= =Fs3V -END PGP SIGNATURE- Accepted: leafnode_1.11.7.rc1-4.diff.gz to pool/main/l/leafnode/leafnode_1.11.7.rc1-4.diff.gz leafnode_1.11.7.rc1-4.dsc to pool/main/l/leafnode/leafnode_1.11.7.rc1-4.dsc leafnode_1.11.7.rc1-4_amd64.deb to pool/main/l/leafnode/leafnode_1.11.7.rc1-4_amd64.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted scanmem 0.07-4 (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Mon, 25 Feb 2008 22:22:05 +0530 Source: scanmem Binary: scanmem Architecture: source i386 Version: 0.07-4 Distribution: unstable Urgency: low Maintainer: Kartik Mistry [EMAIL PROTECTED] Changed-By: Kartik Mistry [EMAIL PROTECTED] Description: scanmem- Locate and modify a variable in a running process Changes: scanmem (0.07-4) unstable; urgency=low . * debian/control: + Updated short and long descriptions + Fixed typo of Linux * debian/copyright: + Added license of install-sh Files: 1f828927b31442643ef9fdc53522db6c 814 utils extra scanmem_0.07-4.dsc e5852103a83aa3e83ef3c66c98ae2bfd 2285 utils extra scanmem_0.07-4.diff.gz c54c6383285c86c6637cebc2904df38a 27686 utils extra scanmem_0.07-4_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHwqxafY3dicTPjsMRArx2AJ4yX8RU9YchGbADksLyBZszHfUWxwCfV+vv k2gCZWdJlqgNyts15Nw/D6g= =Wum+ -END PGP SIGNATURE- Accepted: scanmem_0.07-4.diff.gz to pool/main/s/scanmem/scanmem_0.07-4.diff.gz scanmem_0.07-4.dsc to pool/main/s/scanmem/scanmem_0.07-4.dsc scanmem_0.07-4_i386.deb to pool/main/s/scanmem/scanmem_0.07-4_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted boa 0.94.14rc21-3 (source amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Thu, 07 Feb 2008 23:15:51 -0500 Source: boa Binary: boa Architecture: source amd64 Version: 0.94.14rc21-3 Distribution: unstable Urgency: low Maintainer: Francois-Denis Gonthier [EMAIL PROTECTED] Changed-By: Francois-Denis Gonthier [EMAIL PROTECTED] Description: boa- Lightweight and high performance web server Closes: 438707 449074 458855 Changes: boa (0.94.14rc21-3) unstable; urgency=low . * Access log garbled (Closes: #449074) * Fixed the lfs-support patch, which produced incorrect logfiles on 32 bits machines, and in the same blow removed all build-time warnings which were probably not as harmless as I initially thought. * Removed port detection routines. (Closes: #458855) * dpkg-www: Invalid characters in input. (Closes: #438707) * Removed debconf template and its translations. This package no longer needs debconf. Files: cfa4d6417524c82c768d75f6ee891db7 641 web optional boa_0.94.14rc21-3.dsc f98e33553c84566ac9f4ec97ebc13666 19295 web optional boa_0.94.14rc21-3.diff.gz 347be8bf98c0de634d1a28e2828e8c6d 122574 web optional boa_0.94.14rc21-3_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHwrVqLARVQsm1XawRAk1DAKCfJ3UV7spuqn3qgmquMOZKOdQCkgCgslNm lYF0nDUsxiktvm2DqDLCAs8= =jVQ7 -END PGP SIGNATURE- Accepted: boa_0.94.14rc21-3.diff.gz to pool/main/b/boa/boa_0.94.14rc21-3.diff.gz boa_0.94.14rc21-3.dsc to pool/main/b/boa/boa_0.94.14rc21-3.dsc boa_0.94.14rc21-3_amd64.deb to pool/main/b/boa/boa_0.94.14rc21-3_amd64.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted labplot 1.6.0.1-1 (source i386)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Format: 1.7
Date: Sun, 24 Feb 2008 01:29:56 +0100
Source: labplot
Binary: labplot
Architecture: source i386
Version: 1.6.0.1-1
Distribution: unstable
Urgency: low
Maintainer: Helen Faulkner [EMAIL PROTECTED]
Changed-By: Frank S. Thomas [EMAIL PROTECTED]
Description:
labplot- data plotting and function analysis tool for KDE
Closes: 313971 409551 435209 458444
Changes:
labplot (1.6.0.1-1) unstable; urgency=low
.
* New upstream release (Closes: #458444).
- Fixes mistakes in po/de.po, thanks to Jens Seidel (Closes: #313971).
- Does not crash when deleting two graphs (Closes: #409551).
* Rewrote debian/copyright in the machine-readable format that is outlined
in http://wiki.debian.org/Proposals/CopyrightFormat and clarified some
license issues (Closes: #435209).
* debian/patches/:
- Removed build-with-gcc4.3.patch and fix-autoconf-2.6-compatibility.patch,
these have been incorporated upstream.
- Readded use-pkg-config-instead-of-magick-config.patch which was added
in 1.5.1-1 but got lost in 1.5.1.6-1.
- Added use-debians-qwtplot3d-qt3.patch to modify configure.in in order to
search for qwtplot3d-qt3 (Debian's Qt 3 flavour of QwtPlot3D) instead of
qwtplot3d.
* debian/rules:
- Explicitly passed --enable-FEATURE to configure for all features labplot
should be built with. Most of these correspond to a library development
package in Build-Depends.
- Removed VTK_DIR=/usr from the configure invocation. It is useless
because the build-dependency on libvtk4-dev was removed in 1.5.0.5-1.
- Include debian/debiandirs (if it exists) so that $(configkde) is not
empty when running configure.
- Call configure with the --build and --host options as suggested in the
section Calling GNU configure properly in autotools-dev's
README.Debian.
* debian/control:
- Added to Build-Depends: libjasper-dev (it was implicitly pulled in by
libmagick9-dev, but configure checks for it), libhdf5-serial-dev (new
feature in 1.6.0), libqwtplot3d-qt3-dev and liborigin-dev (these are
required so that labplot does not use the included copies of these
libraries), qhull-bin (in order to prevent labplot from shipping its
own /usr/bin/qdelaunay).
- Added Vcs-{Git,Browser} fields to the source stanza.
- Added myself to Uploaders with Helen's kind permission. Thanks!
* Do not build the included libraries in liborigin-20070926 and qwtplot3d
(libLabPlotorigin.so.* and libLabPlotqwtplot3d.so.*), use the system
libraries provided by the liborigin-dev and libqwtplot3d-qt3 packages
instead.
* Removed debian/labplot.manpages and debian/opj2dat.1 because labplot does
not include /usr/bin/opj2dat anymore. This binary is now provided by the
opj2dat package.
* debian/override:
- Removed the warning binary-without-manpage because labplot includes a
manpage for LabPlot as well as for labplot.
- Removed the package-name-doesnt-match-sonames warnings for
libLabPlotorigin0 and libLabPlotqwtplot3d0 because these libraries are
not included in this package anymore.
* Bumped debhelper compat level from V5 to V6 since this is the current
recommended level and raised the build dependency to debhelper (= 6).
Files:
da8127415960211873aee437eb4606bd 1117 kde optional labplot_1.6.0.1-1.dsc
50dd3033f35003d68d5a4e54336cd6c3 11903145 kde optional
labplot_1.6.0.1.orig.tar.gz
7490b6a6ad4031b9c5c9f3cbbae7ea52 11467 kde optional labplot_1.6.0.1-1.diff.gz
8ea0a31ff7632032329742642a15 6828726 kde optional
labplot_1.6.0.1-1_i386.deb
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
iD8DBQFHwq5uft6HNdxCZCkRAkM8AJ9CX93YaePXEpz5lt9k1O0HcFGlXwCeOZyC
2E7TPH2bgBoNn3Dxd4CdEyQ=
=GBUQ
-END PGP SIGNATURE-
Accepted:
labplot_1.6.0.1-1.diff.gz
to pool/main/l/labplot/labplot_1.6.0.1-1.diff.gz
labplot_1.6.0.1-1.dsc
to pool/main/l/labplot/labplot_1.6.0.1-1.dsc
labplot_1.6.0.1-1_i386.deb
to pool/main/l/labplot/labplot_1.6.0.1-1_i386.deb
labplot_1.6.0.1.orig.tar.gz
to pool/main/l/labplot/labplot_1.6.0.1.orig.tar.gz
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted greylistd 0.8.6-0.1 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Mon, 25 Feb 2008 12:40:48 +0100 Source: greylistd Binary: greylistd Architecture: source all Version: 0.8.6-0.1 Distribution: unstable Urgency: low Maintainer: Julien Danjou [EMAIL PROTECTED] Changed-By: Morten Werner Forsbring [EMAIL PROTECTED] Description: greylistd - Greylisting daemon for use with Exim 4 Closes: 400089 460151 Changes: greylistd (0.8.6-0.1) unstable; urgency=low . * Non-maintainer upload acknowledged by maintainer. * Applied patch from Petter Reinholdtsen which add LSB dependency info to init.d-script. (Closes: #460151) * Applied patch from David L. Anselmi which fixes a syntax error in exim4-acl-example.txt. (Closes: #400089) Files: 128578973a751e2ac5110693d1e3d9d6 558 mail optional greylistd_0.8.6-0.1.dsc e0285a1e5da81eb605e58804d2347084 51963 mail optional greylistd_0.8.6-0.1.tar.gz 004c1f8ef8c39100f38b1e0f90d59e6b 51602 mail optional greylistd_0.8.6-0.1_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHwrh9w951rgNrq40RAp//AKCe3Wcu6vfEVLFZtnXLnAMLXN31TACgwagX b2IzRzPXQU4FAjh40L3cBPE= =jfGx -END PGP SIGNATURE- Accepted: greylistd_0.8.6-0.1.dsc to pool/main/g/greylistd/greylistd_0.8.6-0.1.dsc greylistd_0.8.6-0.1.tar.gz to pool/main/g/greylistd/greylistd_0.8.6-0.1.tar.gz greylistd_0.8.6-0.1_all.deb to pool/main/g/greylistd/greylistd_0.8.6-0.1_all.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted dictionaries-common 0.96.1 (source all)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Format: 1.7
Date: Mon, 25 Feb 2008 13:40:47 +0100
Source: dictionaries-common
Binary: dictionaries-common dictionaries-common-dev
Architecture: source all
Version: 0.96.1
Distribution: unstable
Urgency: low
Maintainer: Agustin Martin Domingo [EMAIL PROTECTED]
Changed-By: Agustin Martin Domingo [EMAIL PROTECTED]
Description:
dictionaries-common - Common utilities for spelling dictionary tools
dictionaries-common-dev - Developer tools and Policy for spelling dictionary
tools
Closes: 467344
Changes:
dictionaries-common (0.96.1) unstable; urgency=low
.
* policy/dsdt-policy.xml.in:
- Upgrade myspell mozilla stuff to the new iceape-browser,
iceweasel and icedove names
* scripts/debhelper/installdeb.in:
- Make sure $no_pre_post is defined for installdeb-aspell
(Closes: #467344).
* scripts/system/{a,i}spell-autobuildhash:
- Update Copyright years and string.
- Better info about the --debug option.
- Removed some trailing whitespace
Files:
53794a7a5a48b9020f597c7a4f0e0814 962 text standard
dictionaries-common_0.96.1.dsc
78445364c8133cf013b9f355935bba84 289789 text standard
dictionaries-common_0.96.1.tar.gz
5c8feb7f31c1ad524cbe95a95796414b 269696 text standard
dictionaries-common_0.96.1_all.deb
3598a8e1a26343ab123517c080670054 109442 devel optional
dictionaries-common-dev_0.96.1_all.deb
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
iD8DBQFHwrhiTShHqj72DpwRAlDrAKCAOrVyd7/cv1gEZ3Q93TkMTKTN5gCfbtCl
IkU+DSPjdY3WYPYu3QnSzwg=
=OESB
-END PGP SIGNATURE-
Accepted:
dictionaries-common-dev_0.96.1_all.deb
to pool/main/d/dictionaries-common/dictionaries-common-dev_0.96.1_all.deb
dictionaries-common_0.96.1.dsc
to pool/main/d/dictionaries-common/dictionaries-common_0.96.1.dsc
dictionaries-common_0.96.1.tar.gz
to pool/main/d/dictionaries-common/dictionaries-common_0.96.1.tar.gz
dictionaries-common_0.96.1_all.deb
to pool/main/d/dictionaries-common/dictionaries-common_0.96.1_all.deb
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted tor 0.2.0.20-rc-1 (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Mon, 25 Feb 2008 13:54:58 +0100 Source: tor Binary: tor tor-dbg Architecture: source i386 Version: 0.2.0.20-rc-1 Distribution: experimental Urgency: low Maintainer: Peter Palfrader [EMAIL PROTECTED] Changed-By: Peter Palfrader [EMAIL PROTECTED] Description: tor- anonymizing overlay network for TCP tor-dbg- debugging symbols for Tor Changes: tor (0.2.0.20-rc-1) experimental; urgency=low . * New upstream version. * Change the default for MAX_FILEDESCRIPTORS in our init script to depend on the number of system-wide available file descriptors: /proc/sys/fs/file-max is bigger than 80k, set ulimit -n to 32k, if it's greater than 40k set the limit to 16k, and when greater than 10k our limit shall be 8k descriptors. If there are less than 20k FDs in the entire system default to a limit of only 1024. . Big servers at the moment regularly use more than 10k FDs, so our old default of 8k no longer is sufficient. On the other hand we don't want lower end systems to run out of FDs on Tor's account. * If we run as root also apply debian defaults. * Add User=debian-tor and Group=debian-tor to debian defaults. That allows us to start Tor as root and have it setuid/setgid to the target user. * Change the init script to start Tor as root. Now we should be able to bind to low port. Files: 8049962934e0bdaf4e62f4b2268c4ecd 738 comm optional tor_0.2.0.20-rc-1.dsc 0ff19d24294896d7cf6757820a2cb41e 1557332 comm optional tor_0.2.0.20-rc.orig.tar.gz d5454e76443d93c36cc1c059a47dd80d 73274 comm optional tor_0.2.0.20-rc-1.diff.gz ebbf864c931ea6c8df30eeaba06101ad 1194904 comm optional tor_0.2.0.20-rc-1_i386.deb 5900d710642e6b076742a37f7f85c701 793996 comm extra tor-dbg_0.2.0.20-rc-1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHwr/jz/ccs6+kS90RAvJxAJsF6FWCLRhuOgECT1yGaciTZnjJGwCgmJtW sSZlF5D8Tu4apyF5YYUDXlM= =ngjU -END PGP SIGNATURE- Accepted: tor-dbg_0.2.0.20-rc-1_i386.deb to pool/main/t/tor/tor-dbg_0.2.0.20-rc-1_i386.deb tor_0.2.0.20-rc-1.diff.gz to pool/main/t/tor/tor_0.2.0.20-rc-1.diff.gz tor_0.2.0.20-rc-1.dsc to pool/main/t/tor/tor_0.2.0.20-rc-1.dsc tor_0.2.0.20-rc-1_i386.deb to pool/main/t/tor/tor_0.2.0.20-rc-1_i386.deb tor_0.2.0.20-rc.orig.tar.gz to pool/main/t/tor/tor_0.2.0.20-rc.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted libtime-piece-perl 1.12-1 (source amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Mon, 25 Feb 2008 14:38:04 +0200 Source: libtime-piece-perl Binary: libtime-piece-perl Architecture: source amd64 Version: 1.12-1 Distribution: unstable Urgency: low Maintainer: Debian Perl Group [EMAIL PROTECTED] Changed-By: Niko Tyni [EMAIL PROTECTED] Description: libtime-piece-perl - Perl module for object oriented time objects Closes: 464619 467267 Changes: libtime-piece-perl (1.12-1) unstable; urgency=low . [ gregor herrmann ] * debian/control: Added: Vcs-Svn field (source stanza); Vcs-Browser field (source stanza); Homepage field (source stanza). Removed: XS- Vcs-Svn fields. * New upstream release. (Closes: #467267) * debian/watch: Use dist-based URL. * Set Standards-Version to 3.7.3 (no further changes needed). * Install README directly from debian/rules. * debian/rules: - build in $(CURDIR)/debian/$(PACKAGE) instead of debian/tmp - drop call to dh_install and remove .install file - move dh_clean before make realclean - use PREFIX and DESTDIR for $(MAKE) install - let install-stamp depend on build-stamp - don't install empty /usr/share/perl5 directory - remove build-stamp and install-stamp with dh_clean * debian/copyright: - add upstream URL - clarify referenced perl license terms - be more verbose on listing authors * debian/rules: delete /usr/share/perl5 only if it exists. * Add patch manpage_fix_chars.patch to fix non-ascii chars in manpage, thanks to Adam Borowski (closes: #464619). Add quilt framework. * Set debhelper compatibility level to 6. . [ Niko Tyni ] * Switch to my @debian.org email address. * Update and reformat debian/copyright, mentioning the lack of upstream copyright notices (see #467435). Files: b79bc807074cd5e99c4b7d15d34e22da 975 perl optional libtime-piece-perl_1.12-1.dsc 7608cd1a565060dbef1f7e2d2a14efb9 20536 perl optional libtime-piece-perl_1.12.orig.tar.gz 380410d1810fd0092245d79013d18096 3921 perl optional libtime-piece-perl_1.12-1.diff.gz f42a19340a20c45e3f02186012e84da6 27698 perl optional libtime-piece-perl_1.12-1_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHwriyiyizGWoHLTkRAiZgAJ9OfN5eJcuFTcWN7xJdWPK2+ZzlEwCeNfiy lwYiSUhgP/VI/XyW05S7kmc= =vrjq -END PGP SIGNATURE- Accepted: libtime-piece-perl_1.12-1.diff.gz to pool/main/libt/libtime-piece-perl/libtime-piece-perl_1.12-1.diff.gz libtime-piece-perl_1.12-1.dsc to pool/main/libt/libtime-piece-perl/libtime-piece-perl_1.12-1.dsc libtime-piece-perl_1.12-1_amd64.deb to pool/main/libt/libtime-piece-perl/libtime-piece-perl_1.12-1_amd64.deb libtime-piece-perl_1.12.orig.tar.gz to pool/main/libt/libtime-piece-perl/libtime-piece-perl_1.12.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted wspanish 1.0.20 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Mon, 25 Feb 2008 13:56:58 +0100 Source: wspanish Binary: wspanish Architecture: source all Version: 1.0.20 Distribution: unstable Urgency: low Maintainer: Agustin Martin Domingo [EMAIL PROTECTED] Changed-By: Agustin Martin Domingo [EMAIL PROTECTED] Description: wspanish - The Spanish dictionary words for /usr/share/dict Closes: 437719 Changes: wspanish (1.0.20) unstable; urgency=low . * debian/control: - Bumped standards version to 3.7.3. No changes needed * Improved debian/copyright. * Recoded to utf8, Debian's default encoding. Needs recode build-dependency (Closes: #437719). Files: ab8dedcc4dff7ff1dce3d2fa4c2ad49a 568 text optional wspanish_1.0.20.dsc a8c0d171fff81a172aa2ddb12c05c3ed 254084 text optional wspanish_1.0.20.tar.gz 7684fe1084de1962a508f68c00565ed4 259200 text optional wspanish_1.0.20_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHwrthTShHqj72DpwRAraFAJ9dKHZgxq7bdWc2lQSV5ErsQa7fXwCcCpYd 5bkxDWweMm4vXwd5XrOdwzs= =BUwM -END PGP SIGNATURE- Accepted: wspanish_1.0.20.dsc to pool/main/w/wspanish/wspanish_1.0.20.dsc wspanish_1.0.20.tar.gz to pool/main/w/wspanish/wspanish_1.0.20.tar.gz wspanish_1.0.20_all.deb to pool/main/w/wspanish/wspanish_1.0.20_all.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted gnome-specimen 0.4-2 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Mon, 25 Feb 2008 22:27:15 +0530 Source: gnome-specimen Binary: gnome-specimen Architecture: source all Version: 0.4-2 Distribution: unstable Urgency: low Maintainer: Kartik Mistry [EMAIL PROTECTED] Changed-By: Kartik Mistry [EMAIL PROTECTED] Description: gnome-specimen - Simple font preview and compare application for GNOME Changes: gnome-specimen (0.4-2) unstable; urgency=low . [Kartik Mistry] * debian/control: + Fixed typo GNOME in short description Files: 00a395ff7ca45692817652a0711d95e3 938 gnome optional gnome-specimen_0.4-2.dsc bec1200c17857df2fd5ec146bb1c8a0e 3256 gnome optional gnome-specimen_0.4-2.diff.gz dfc95b40326b205c992b74aadb7897c9 70794 gnome optional gnome-specimen_0.4-2_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHwr0EfY3dicTPjsMRAlpUAJ0dtjRp01hTzqdhEEbqlfAn8u8jVgCeLYtP DkxQuuK1491Rs8DRCWrnAus= =U+sv -END PGP SIGNATURE- Accepted: gnome-specimen_0.4-2.diff.gz to pool/main/g/gnome-specimen/gnome-specimen_0.4-2.diff.gz gnome-specimen_0.4-2.dsc to pool/main/g/gnome-specimen/gnome-specimen_0.4-2.dsc gnome-specimen_0.4-2_all.deb to pool/main/g/gnome-specimen/gnome-specimen_0.4-2_all.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
