Bug#467258: general: Net-install CD still defaults to asking for CD in aptitude
Package: general Severity: normal 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. -- System Information: Debian Release: 4.0 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-6-amd64 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: How to cope with patches sanely
On Sun, 24 Feb 2008, Charles Plessy wrote: Therefore we did not make progress since the beginning of the discussion: You're trying to make progress somewhere where it's not expected. - The most efficient way to deal with changes to the sources for the packager is to use his preferred tools. That should stay as it is. - We do not know if the whole concept of breaking up the monolithic diff into logical units is something that the persons who often do NMUs in Debian are intersted in. Seperating logical changes has always been useful to understand the changes and is thus required for any independant reviewer who hasn't access to the VCS where the changes are reviewable separately. - When modifying a package that uses dpatch, quilt or simple-patchsys, developpers have to find out by themselves if the target for patching the sources is patch, apply-patches or apply-dpatches. Once the new dpkg-source format is in standard use, those rules disappear completely... because they are no more needed during build. Frank Lichtenheld and myself have started hacking on dpkg-source with the goal to support an extend wigpen and possibly even more. I'd encourage interested parties to subscribe to debian-dpkg to follow discussions there. http://lists.debian.org/debian-dpkg/2008/02/msg00012.html http://lists.debian.org/debian-dpkg/2008/02/msg00036.html We're working in the sourcev3 branch of dpkg's git repo. We've only doing some ground work for now, but we've been doing good progress and I expect the work on new features to start pretty soon. http://git.debian.org/?p=dpkg/dpkg.git;a=shortlog;h=sourcev3 (Subscribe to the PTS with cvs keyword and you'll get git commit notice in live :-)) 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]
Bug#467258: marked as done (general: Net-install CD still defaults to asking for CD in aptitude)
Your message dated Sun, 24 Feb 2008 02:06:14 -0800 with message-id [EMAIL PROTECTED] and subject line Re: Bug#467258: general: Net-install CD still defaults to asking for CD in aptitude has caused the Debian Bug report #467258, regarding general: Net-install CD still defaults to asking for CD in aptitude to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact [EMAIL PROTECTED] immediately.) -- 467258: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=467258 Debian Bug Tracking System Contact [EMAIL PROTECTED] with problems ---BeginMessage--- Package: general Severity: normal 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. -- System Information: Debian Release: 4.0 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-6-amd64 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) ---End Message--- ---BeginMessage--- On Sat, 23 Feb 2008, 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 because it's assumed that pulling files which are known to be on the CD you used to install the system will be faster than downloading. It's quite trivial to remove them from the sources.list if you know this to not be the case. [Removal is far easier then actually adding the proper entries, so having them present is the right course of action.] Don Armstrong -- What I can't stand is the feeling that my brain is leaving me for someone more interesting. http://www.donarmstrong.com http://rzlab.ucr.edu ---End Message---
Re: triggers in dpkg, and dpkg maintenance
Hi Ian, On Fri, 22 Feb 2008, Ian Jackson wrote: There is in my opinion no reason why this code should not be merged into sid's dpkg immediately - although there may be some merge conflicts by now. (I haven't been playing merge catch-up since I don't presently feel that my changes are going to be accepted.) This is the only point to which I agree in your mail. 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. Guillem has some responsibility in the delay here but he's perfectly aware of it. I've been nagging him a bit to merge your work and he told us that he has been orphaning other packages to be able to work more on dpkg. His latest plans are still to merge your triggers work for 1.14.17 AFAIK. During some of the discussions surrounding my return to dpkg development, the view was expressed that I ought to do some work to persuade particularly Guillem Jover of my usefulness and competence. I was encouraged by various members of the current dpkg maintenance team to pull my weight by doing some bug triage and fixing. For other people, that was mainly me AFAIK. I request that the current dpkg maintainers formally reinstate me as a maintainer of the package, and that they agree that I should merge my triggers branch, and other fixes, into the main dpkg git tree so that it may be uploaded. 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 FWIW, each commit pushed generates a mail sent to the PTS and I believe that all main developers review changes that way (thus it's important to have good log messages and changes committed in separate logical steps). I would like to see this happen without getting into bikeshedding about the proper use of git (and without pointless revision log polishing and without history-losing merges). FWIW, IMO, either you follow the rules and you will be authorized to commit on your own after some time, or you don't and you keep sending us patches to merge (and you'll have to wait for someone to integrate your work). Make your choice, invest a bit more time in preparing something ready to be merged or wait... I made all the path from external contributor to regular contributor and I've been added to Uploaders recently. You can do it too I'm sure. I had the chance to have djpig available to review my work and you're a bit more dependant on Guillem to get started, but hopefully this won't stay a problem for too long. And last point, when we have problems withing the -dpkg team (and it happens, we're only humans), we tend to resolve them by discussion on #debian-dpkg and not by sending mails to -devel. 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: Looking for co-maintainer for mercurial
On Thu, Feb 21, 2008 at 4:27 PM, Ondrej Certik [EMAIL PROTECTED] wrote: On Wed, Feb 20, 2008 at 9:10 PM, William Pitcock [EMAIL PROTECTED] wrote: Hi, I'll be happy to help with this package. Hi, I'll help with this package too, because I use Mercurial everyday. Let's maintain it in: http://wiki.debian.org/Teams/PythonAppsPackagingTeam ? There are many good DD's around the Python Applications Packaging Team and the Debian Python Modules Team, because generally, this is a Python program, so they may help with many python related issues. Any news on this? Do you agree with me importing to package to Python Applications Packaging Team (PAPT) and changing it's maintainer to PAPT? Ondrej -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
intend to take over gpsk31 maintenance
I intend to take over gpsk31 package maintenance from the previous maintainer, Carlos Barros. I think this would be more convenient as I am also the upstream maintainer. Carlos, I you read this please respond if you object. Thanks, Joop pa3aba at debian dot org -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: How to cope with patches sanely -- Debian New Maintainers'
On Sat, Feb 09, 2008 at 10:53:55AM +0100, Patrick Schoenfeld wrote: (BTW. there is no need to CC me with your answers, I did not ask for that as I am subscribed to the list :-) On Sat, Feb 09, 2008 at 12:50:46AM +0100, Pierre Habouzit wrote: quilt is way more powerful to refresh patches when a new upstream occurs. It does what it can do best without having mergeing features, that only an advanced SCM can provide anyways. That does mean quilt is able to refresh patches on upstream changes, so that with luck the maintainer does not have to refresh the patches for changes sources himself? That would be quiet nice, however I still fail to see why this is a reason to prefer quilts *format* as an *exchange format* if quilt itself is not to be used, which is what you say. Who said quilt itself is not to be used? The point of the discussion is that we agree on a patch-exchange format, without forcing an implementation on people. People who like the quilt implementation will still be able and encouraged to use quilt with it. Others might just use vi to edit quilt patches, or git, or something else. Michael -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Looking for co-maintainer for mercurial
Hi, On Sun, 2008-02-24 at 12:30 +0100, Ondrej Certik wrote: On Thu, Feb 21, 2008 at 4:27 PM, Ondrej Certik [EMAIL PROTECTED] wrote: On Wed, Feb 20, 2008 at 9:10 PM, William Pitcock [EMAIL PROTECTED] wrote: Hi, I'll be happy to help with this package. Hi, I'll help with this package too, because I use Mercurial everyday. Let's maintain it in: http://wiki.debian.org/Teams/PythonAppsPackagingTeam ? There are many good DD's around the Python Applications Packaging Team and the Debian Python Modules Team, because generally, this is a Python program, so they may help with many python related issues. Any news on this? Do you agree with me importing to package to Python Applications Packaging Team (PAPT) and changing it's maintainer to PAPT? Ondrej I disagree because mercurial is a very specific tool, and needs to be maintained by people who care about mercurial specifically. But if that is what Vincent wants to do, then that's fine. William signature.asc Description: This is a digitally signed message part
Bug#467274: ITP: pcc -- the portable C compiler
Package: wnpp Severity: wishlist Owner: William Pitcock [EMAIL PROTECTED] Hi, I am interested in pcc for several months, so I intend to package it in Debian. * Package name: pcc Version : 0.9.9 Upstream Author : Anders Magnusson [EMAIL PROTECTED] * URL : http://pcc.ludd.ltu.se/ * License : BSD Programming Lang: C Description : the portable C compiler pcc is the continuation of the portable C compiler source included in ancient Unix. It has been modernized to support C99 standards and other great features. An advantage to using pcc is that it is stricter about code structure than gcc is. To some extent, it is compatible with gcc CFLAGS, but this is not guaranteed. -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 2.6.22-3-amd64 (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: Bug#465334: ITP: speed-game -- A fast paced space-invader style arcade game
Hello: bubulle wrote: We still have a few games of the nineties in the archive which make interesting claims such as high speed or nice graphics and would just seem like jokes on 21st century machines or compared to 21st century games..:-)' hm - expect that Go (http://en.wikipedia.org/wiki/Weiqi) is the most addictive game compared to my quake1 on my 20th century machine (166MMX 128MB DOS), I can't play any interesting today (Celeron500 256MB Lenny). I can write game music modules for a game wich uses a q1-like engine in DFSG-free environment without proprietary hw-acceleration. -- sas ( satie ) - SZERVÁC Attila - zeneszerző - szoftvergazda \ elnökhelyettes - Linux-felhasználók Magyarországi Egyesülete - http://lme.hu/ HU/Budapest - http://321.hu/sas/http://321.hu/Elig -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Practical solutions to: the new style mass tirage of bugs
On Thu, Feb 21, 2008 at 11:31:32PM -0600, John Goerzen wrote: Here are some things that occur to me quickly: I'll be just pointing to existing tools I'm aware of that are related to your points. People probably already know all of them, but since I'm a bit surprised to not having them mentioned in this thread I'll do that. 4) Integration with BTS and $DVCS. I have some code that marks bugs pending when mentioned in a VCS change log. But this could go farther: branches tied to bugs, etc. My workflow for that is using dch + debcommit + tagpending, all in devscripts. With dch I play with the changelog as usual, possibly adding the Closes: #xx entry. Then I commit with debcommit, which reuses the changelog entry as it is. Then I run tagpending which extracts bug numbers from the changelog entry and send the appropriate message to the BTS. I find this quite satisfying, the only extra integration which I would like is alioth-side post-commit hooks (which I believe exists for whatever $VCS) grepping for Closes: #xx lines in commit messages. It won't be life changing, but having them by default on all repos on alioth would be nice. Were you expecting something like this? more/less? 6) Better tools to integrate Debian BTS with upstream BTS. I would love a Uhm, we have bts-link (http://bts-link.alioth.debian.org/) which is quite nice, though I must say that thus far I've been lucky, and madcoder has always made the setup I needed instead of me :-) command-line tool where I could say debforward 123456. It would look up the package name for 123456, figure out from some metadata what type of BTS it uses and where it lives, look up my account on that BTS in ~/.forward, and create a bug report there and mark the Debian one forwarded. Then, if there is no automated mechanism, some scanner at Debian would look for changes on either end and forward them back and forth. I would love this. I guess madcoder already have this kind of information for bts-link, if the information is available somewhere it would be trivial to add this feature to bts (the commandline tool in devscripts, not the BTS of course). Cheers. -- Stefano Zacchiroli -*- PhD in Computer Science ... now what? [EMAIL PROTECTED],cs.unibo.it,debian.org} -%- http://upsilon.cc/zack/ (15:56:48) Zack: e la demo dema ?/\All one has to do is hit the (15:57:15) Bac: no, la demo scema\/right keys at the right time signature.asc Description: Digital signature
Re: dash bug which is affecting release goal
John H. Robinson, IV writes (Re: dash bug which is affecting release goal):
Pierre Habouzit wrote:
echo() { /bin/echo $@ }
echo() { /bin/echo ${1+$@}; }
I believe you mean.
Why ?!
Ian.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: QUESTION: Debian Policy: Manual pages
Bas Zoetekouw writes (Re: QUESTION: Debian Policy: Manual pages): Why a recommends? In order to satisfy the spirit of policy (every binary must have a man page) it would need to be a depends, imo. I think the point of policy is to ensure the manpage exists, not to require that it be installed. I think Suggests is the right dependency. There is nothing wrong with installing a package without its documentation. Ian. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dash bug which is affecting release goal
On Sun, 2008-02-24 at 14:00 +, Ian Jackson wrote:
John H. Robinson, IV writes (Re: dash bug which is affecting release goal):
Pierre Habouzit wrote:
echo() { /bin/echo $@ }
echo() { /bin/echo ${1+$@}; }
I believe you mean.
Why ?!
Because stand-alone $@ is undefined when used in this case. By using ${1
+$@}, it is ensured that $@ always starts with $1.
What a load of POSIX.
William
signature.asc
Description: This is a digitally signed message part
Re: dash bug which is affecting release goal
On Sun, 2008-02-24 at 08:30 -0600, William Pitcock wrote:
On Sun, 2008-02-24 at 14:00 +, Ian Jackson wrote:
John H. Robinson, IV writes (Re: dash bug which is affecting release
goal):
Pierre Habouzit wrote:
echo() { /bin/echo $@ }
echo() { /bin/echo ${1+$@}; }
I believe you mean.
Why ?!
Because stand-alone $@ is undefined when used in this case. By using ${1
+$@}, it is ensured that $@ always starts with $1.
What a load of POSIX.
William
Oops, I mean Because the behaviour of stand-alone $@ is undefined.
William
signature.asc
Description: This is a digitally signed message part
Re: the new style mass tirage of bugs
John Goerzen writes (Re: the new style mass tirage of bugs): Here's the thing. If bugs I submit actually get looked at by a human, and humans are fixing a reasonable percentage of bugs submitted, I don't mind testing things out on new versions whenever I can. I think this is a key point. I've had a number of cases recently where very old bugs of mine have had responses apparently by people other than the maintainer saying `can you reproduce this' or `is this still relevant in the new version'. These messages are IMO useless, in the vast majority of cases. A good test is: what would I do if I were both the maintainer and the bug submitter ? Looking at it that way avoids getting confused, and avoids adopting approaches which just shuffle work about or which even create more work. If I have reported a longstanding bug in a package of mine, I don't usually say to myself `oh look this is years and years old let me see if I can still reproduce it so I can just forget about it if not'. Rather I'll ask `has anything changed in the package which one might expect to have a bearing on this bug'. If the answer is `no' then the bug should stay open until I have effort to actually investigate it. That this might take months or years if the bug is not very important. If the answer is `yes, the package has changed', then the next question is `what is the best way forward'. Sometimes it will be obvious that the code which had the bug has been entirely removed, so that the bug report no longer serves a useful purpose. At other times a quick glance at the relevant code changes shows that actually the changes couldn't fix the reported symptoms. And then there are cases where the best approach is to try it again with the new version. etc. But these decisions cannot be made by unskilled `triagers' who just go around sending emails to what they think of as `stale' bugs. Of course there are packages (OOo and Mozilla are probably examples) which are so huge and so full of bugs that dealing properly with all of the bugs is impossible. In particular, if a package has so many bugs, or is generally so large or in such poor shape, that it is inconceivable that anything but a small inority will ever be properly investigated and fixed, there is no point recording minor bugs in the Debian BTS. That just serves to clutter the bug listings to no useful effect. So I don't mind it at all when then Mozilla maintainers say `is it still doing this crazy thing'. After all I don't even bother reporting most of the bad things Mozilla does; one-offs definitely don't make the cut. If I can't reproduce it then if I were both submitter and maintainer I wouldn't spend any more time on it. So then just closing it is fine. Whether or not a package is like this is probably a question for the maintainer to decide - but if the number of bugs is only a few dozen then I think saying the package is unmaintainable is not a reasonable point of view. Ian. -- 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 writes (Re: dpkg-buildpackage now reorganizing debian/control Depends field??): 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 ? (IMO it has been demonstrated that sorting should not override the package maintainer's specified ordering.) Ian. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Looking for co-maintainer for mercurial
On Sun, Feb 24, 2008 at 12:57 PM, William Pitcock [EMAIL PROTECTED] wrote: Hi, On Sun, 2008-02-24 at 12:30 +0100, Ondrej Certik wrote: On Thu, Feb 21, 2008 at 4:27 PM, Ondrej Certik [EMAIL PROTECTED] wrote: On Wed, Feb 20, 2008 at 9:10 PM, William Pitcock [EMAIL PROTECTED] wrote: Hi, I'll be happy to help with this package. Hi, I'll help with this package too, because I use Mercurial everyday. Let's maintain it in: http://wiki.debian.org/Teams/PythonAppsPackagingTeam ? There are many good DD's around the Python Applications Packaging Team and the Debian Python Modules Team, because generally, this is a Python program, so they may help with many python related issues. Any news on this? Do you agree with me importing to package to Python Applications Packaging Team (PAPT) and changing it's maintainer to PAPT? Ondrej I disagree because mercurial is a very specific tool, and needs to be maintained by people who care about mercurial specifically. But if that is what Vincent wants to do, then that's fine. Well, that's what PAPT is for. All python apps and modules (those go into the DPMT team) share a lot of things in common, they all need the same care when switching from python2.4 to python2.5 etc. You can still require to approve all changes before each upload. Ondrej -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
git bikeshedding (Re: triggers in dpkg, and dpkg maintenance)
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 ? 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. Ian. [1] Well, `git pull' is what needed to be done in August. Now obviously a bit of merge conflict sorting will need to be done. I am obviously volunteering to do this but only if it means I can be sure it will be the last time. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: triggers in dpkg, and dpkg maintenance
Raphael Hertzog writes (Re: triggers in dpkg, and dpkg maintenance): Guillem has some responsibility in the delay here but he's perfectly aware of it. I've been nagging him a bit to merge your work and he told us that he has been orphaning other packages to be able to work more on dpkg. I don't think this is an acceptable answer at this stage. The current maintainers have failed to shit. Now they should get off the pot. My bugfixes for #281057 and #432893, and my implementation of `Breaks' support in dselect, are outstanding too, since early November. Ian. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: How to cope with patches sanely
Le Sun, Feb 24, 2008 at 10:47:05AM +0100, Raphael Hertzog a écrit : - When modifying a package that uses dpatch, quilt or simple-patchsys, developpers have to find out by themselves if the target for patching the sources is patch, apply-patches or apply-dpatches. Once the new dpkg-source format is in standard use, those rules disappear completely... because they are no more needed during build. I must have missed something. I thought that the new format was to keep the debian directory in a tar.gz format. With this format, people who want to modify upstream sources will have to use a patch system. What is the plan to make the patch targets in debian/rules unneeded? Have a nice day (and thank you for your work on a new format for source pacakages.) -- Charles Plessy http://charles.plessy.org Wakō, Saitama, Japan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Looking for co-maintainer for mercurial
William Pitcock wrote: Hi, On Sun, 2008-02-24 at 12:30 +0100, Ondrej Certik wrote: On Thu, Feb 21, 2008 at 4:27 PM, Ondrej Certik [EMAIL PROTECTED] wrote: There are many good DD's around the Python Applications Packaging Team and the Debian Python Modules Team, because generally, this is a Python program, so they may help with many python related issues. Any news on this? Do you agree with me importing to package to Python Applications Packaging Team (PAPT) and changing it's maintainer to PAPT? Ondrej I disagree because mercurial is a very specific tool, and needs to be maintained by people who care about mercurial specifically. But if that is what Vincent wants to do, then that's fine. I'm already in the perl teams and, even if I did not know about the PAPT, I think it is similar. I mean that I think that even if the package is maintained within a team, specific work about one package will be done by the few members that care about it. The PAPT will be add value when python transitions occurs or similar 'global' event in the python world. This is why I asked to be added in the PAPT. Piotr Ożarowski just added me in this alioth project and I plan to upload the current version of mercurial in the SVN today or tomorrow. If it happens that someone willing to work on mercurial packaging (such as William Pitcock) were denied the access to the PAPT on the ground that they do not do other python work, I will reconsider my decision and move mercurial elsewhere (probably in the collab-maint alioth project). But until evidence of that, I consider that PAPT admins are quite reasonable and that hosting mercurial in the PAPT alioth project will add a little more value that in the collab-maint project. And, to answer to a private suggestion, I do not think at all that creating a specific alioth project for mercurial is interesting : there already exist several uptream ML to discuss development, an upstream BTS, several upstream repo, ... So I do not see any benefice to create a new alioth project. Best regards, Vincent -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Looking for co-maintainer for mercurial
Hi, On Sun, 2008-02-24 at 15:59 +0100, Vincent Danjean wrote: William Pitcock wrote: Hi, On Sun, 2008-02-24 at 12:30 +0100, Ondrej Certik wrote: On Thu, Feb 21, 2008 at 4:27 PM, Ondrej Certik [EMAIL PROTECTED] wrote: There are many good DD's around the Python Applications Packaging Team and the Debian Python Modules Team, because generally, this is a Python program, so they may help with many python related issues. Any news on this? Do you agree with me importing to package to Python Applications Packaging Team (PAPT) and changing it's maintainer to PAPT? Ondrej I disagree because mercurial is a very specific tool, and needs to be maintained by people who care about mercurial specifically. But if that is what Vincent wants to do, then that's fine. I'm already in the perl teams and, even if I did not know about the PAPT, I think it is similar. I mean that I think that even if the package is maintained within a team, specific work about one package will be done by the few members that care about it. The PAPT will be add value when python transitions occurs or similar 'global' event in the python world. This is why I asked to be added in the PAPT. Piotr Ożarowski just added me in this alioth project and I plan to upload the current version of mercurial in the SVN today or tomorrow. If it happens that someone willing to work on mercurial packaging (such as William Pitcock) were denied the access to the PAPT on the ground that they do not do other python work, I will reconsider my decision and move mercurial elsewhere (probably in the collab-maint alioth project). But until evidence of that, I consider that PAPT admins are quite reasonable and that hosting mercurial in the PAPT alioth project will add a little more value that in the collab-maint project. And, to answer to a private suggestion, I do not think at all that creating a specific alioth project for mercurial is interesting : there already exist several uptream ML to discuss development, an upstream BTS, several upstream repo, ... So I do not see any benefice to create a new alioth project. PAPT is indeed fine if that's the way you want to go. I'll bounce over to IRC and ask that my account is added. William signature.asc Description: This is a digitally signed message part
Re: dash bug which is affecting release goal
On 2/24/08, William Pitcock [EMAIL PROTECTED] wrote:
On Sun, 2008-02-24 at 14:00 +, Ian Jackson wrote:
John H. Robinson, IV writes (Re: dash bug which is affecting release
goal):
Pierre Habouzit wrote:
echo() { /bin/echo $@ }
echo() { /bin/echo ${1+$@}; }
I believe you mean.
Why ?!
Because stand-alone $@ is undefined when used in this case. By using ${1
+$@}, it is ensured that $@ always starts with $1.
Expression ${1+$@} means if $1 exists use $@, otherwise nothing.
It's a workaround for a bug in some old bash version which erroneously
converted $@ in case of empty command line into a single empty
argument. I think in new releases it isn't necessary to account for
this.
--
Sergei Golovan
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dash bug which is affecting release goal
* William Pitcock:
On Sun, 2008-02-24 at 14:00 +, Ian Jackson wrote:
John H. Robinson, IV writes (Re: dash bug which is affecting release goal):
Pierre Habouzit wrote:
echo() { /bin/echo $@ }
echo() { /bin/echo ${1+$@}; }
I believe you mean.
Why ?!
Because stand-alone $@ is undefined when used in this case. By using ${1
+$@}, it is ensured that $@ always starts with $1.
What a load of POSIX.
| If there are no positional parameters, the expansion of '@' shall
| generate zero fields, even when '@' is double-quoted.
Given that requirement, Sergei's explanation as an ancient bash bug
makes more sense.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Practical solutions to: the new style mass tirage of bugs
On Fri, Feb 22, 2008 at 05:19:50PM +0100, Roland Mas wrote: Now, if I could run an 'apt-get source -t unstable foo' and create my patch against the resulting source package, and be sure that the maintainer won't reject it on the grounds of the patch not being against the head (or latest, or whatever) of whichever $DVCS they happen to be using, then things would be a little better. I believe that's exactly what debcheckout(1) is for. Indeed. As for generating the patch, maybe debcommit(1) could be extended to provide a --diff-only option that would just output a patch rather than try to actually commit. And while we're at it, maybe there could I've just committed such a change, try debcommit --diff from ... well, only from debcheckout devscripts for the moment. be a debcheckout --update option that would update the working copy to the current state of the repository. I see less the point of this, but maybe it's just me. What we are basically doing with these features is to abstract over a particular $VCS. The initial point about debcheckout was most about retrieving the information about where a given package is maintained and use the appropriate tool to check it out. It was not (at least in my mind) to enable a developer not knowing a given $VCS to use it, so I'm a bit scared about this proposal: can't the developer just do $VCS update from the last working copy she checked out? Cheers. -- Stefano Zacchiroli -*- PhD in Computer Science ... now what? [EMAIL PROTECTED],cs.unibo.it,debian.org} -%- http://upsilon.cc/zack/ (15:56:48) Zack: e la demo dema ?/\All one has to do is hit the (15:57:15) Bac: no, la demo scema\/right keys at the right time signature.asc Description: Digital signature
Re: Looking for co-maintainer for mercurial
Vincent Danjean wrote: Hi, I'm the maintainer of the DSCM mercurial. At this moment, I do not have lot of free time. Moreover, I'm not a big user of mercurial anymore (I often use git that I find less intuitive but more powerful). So I'm looking for co-maintainer of this package. I would be very disappointed if mercurial is not in a good shape for the next release. Anyone interested ? (I think the collab-maint alioth project would be a good place for further development) 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 For now, there is 18 opened bugs : For people willing to help, I think one of the first things to do is check for each bug in the BTS if it is fixed upstream or not (the 1.0 release is not very far) and, if not, to ensure the bug has been forwarded upstream. Regards, Vincent -- Vincent Danjean GPG key ID 0x9D025E87 [EMAIL PROTECTED] GPG key fingerprint: FC95 08A6 854D DB48 4B9A 8A94 0BF7 7867 9D02 5E87 Unofficial pacakges: http://www-id.imag.fr/~danjean/deb.html#package APT repo: deb http://perso.debian.org/~vdanjean/debian unstable main -- 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
Package: gtkimageview Version: 1.5.0-1 Severity: normal gtkimageview 1.6.0 has been released. I have written Perl bindings, but they only compile against the new version, so I would appreciate the new version of the library being packaged so that I can do the same for the Perl bindings. I would also be prepared to take over maintaining the library, if you don't have time. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
git bikeshedding (Re: triggers in dpkg, and dpkg maintenance)
Jarg Sommer writes (Re: triggers in dpkg, and dpkg maintenance): Ian Jackson [EMAIL PROTECTED] wrote: 24 Oct 2007 - Raphael Hertzog asks me to `git-rebase', edit the email address in my git commit logs, and so forth, allegedly in order to make my changes easier to review. At the time I was reliably informed by git experts that published branches should not be rebased. As a rather more experienced git user it seems clear to me now that I was right to resist. There's no problem starting a new branch and rebasing this. % git branch trigger-new trigger % git rebase master trigger-new But for the reasons which were discussed at length on debian-dpkg in October, this is not a good idea. Sadly I was not able to persuade Raphael. One should not rebase a git branch which has had other branches taken from it, nor should one rebase a git branch which has ever been published (at least, unless it has been published with a warning announcing that it might be rebased). Both of these practices lead to severe problems. The triggers branch has both properties: my experimental flex parser branch is based off the triggers branch, as well as various smaller bugfix branches, and obviously the branch has been published by my various mailing list announcements and bug reports. If the main git branch pulls a rebased version of my triggers branch rather than the original, or if the same thing is attempted with patch and diff, then attempts to merge the main head back into the flex parser branch fail with conflicts. Raphael assured me that it would work just fine so I actually tried it, and so did Raphael later. The results were a pile of conflicts to fix up, as I had predicted. See the results of the workflow that Raphael is suggesting: http://lists.debian.org/debian-dpkg/2007/10/msg00206.html You probably want to skip the discussion and look at the transcript, about two thirds of the way down. Note that this is Raphael's message and the transcript he is presenting is what he apparently considers acceptable behaviour! The reason it doesn't work well is that rebase, like patch/diff, discards the revision history. git no longer knows when trying to do the second merge that the triggers commits on the main branch are the same as the ones on the flex branch. So it tries to apply them again, which doesn't work. git's algorithm is clever enough, like cvs's but unlike some version control systems', to spot the identical changes in cases where there is no interaction between the flex and triggers changes. But there are quite a few such interactions and every one generate a spurious conflict. This can be avoided by using git properly. It already knows how to track which changes have already been merged. If you do it the right way (ie, just merge from my branch) then there are no conflicts. Everything is automatic; it just does the right thing. Of course you get a slightly messier revision history because the main dpkg revision history will then contains everything I actually did, rather than some sanitised rewrite of history. I think this is good because I want to know the actual context of a change, but Raphael thinks it is a problem because he wants a clean and pretty revision log. Even if you thought a revision log containing an invented history was a good idea, it's surely not worth manually resolving conflicts to get it - especially in a project which has about three or four branches and three or four committers. Ian. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: QUESTION: Debian Policy: Manual pages
* Ian Jackson [EMAIL PROTECTED] [080224 09:18]: Bas Zoetekouw writes (Re: QUESTION: Debian Policy: Manual pages): Why a recommends? In order to satisfy the spirit of policy (every binary must have a man page) it would need to be a depends, imo. I think the point of policy is to ensure the manpage exists, not to require that it be installed. I think Suggests is the right dependency. There is nothing wrong with installing a package without its documentation. Ian. IANADD, but as a user, I disagree. Policy [12.1] states: Each program, utility, and function should have an associated manual page included in the same package. There is a big difference between a man page and more complete documentation like a User Manual. I _expect_ a man page for every executable. A Depends, in my mind, clearly satisfies the policy requirement, as the man page will be available unless I use dpkg --force-* or some other drastic measure to override the depends. A Recommends may satisfy this (especially now that apt defaults to installing them), but not quite as clearly. Harshula, from your description it is not clear if c.tar.gz contains substantial documentation beyond man pages. If c.tar.gz contains very little besides man pages and basic documentation, then Depend on c.deb, and leave the man pages there. If the tarball contains a lot of other documentation, my preference as a user would be to have the man pages moved into the binary a.deb and b.deb packages, and Recommend or Suggest c.deb (without the man pages). If you are making one source package with three binary packages, moving the man pages to a different binary package is trivial. If you are making three separate source packages, I would still prefer to have the man pages copied to the packages with their corresponding executable, with a note in the README.Debian identifying the originating tarball. I know this is more work (in the separate source package case), but as a user I would appreciate not having to keep around a large documentation package just to get man pages. ...Marvin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Practical solutions to: the new style mass tirage of bugs
On Sat, Feb 23, 2008 at 01:03:01PM -0800, Don Armstrong wrote: If there are sets of usertags which are in common use by a reasonable number of diverse packages, and are something that would normally be put on the [EMAIL PROTECTED] user (that is to say, make them visible by default) then file a bug against bugs.debian.org askiing for that tag to be made a real tag. That's the best way to standardize usertags which are currently not bts-wide tags. Ack on the general principle. However, the need which was pointed out to seemed to me more than a tag: in my head it was distilled as priority, as available in other bug tracking systems. This is something that can be encoded with usertags, but such an encoding does not have good properties such as mutual exclusion of alternative priorities. In this respect, if I were the one to ask something to be integrated in the BTS, I would ask for the implementation of the priority feature, which is more than just adding a new tag. [ FWIW, I would second the proposers of such a feature, but right now I'm offline and can't even check if it is already there as a feature request, possibly marked as wontfix ... ] Cheers. -- Stefano Zacchiroli -*- PhD in Computer Science ... now what? [EMAIL PROTECTED],cs.unibo.it,debian.org} -%- http://upsilon.cc/zack/ (15:56:48) Zack: e la demo dema ?/\All one has to do is hit the (15:57:15) Bac: no, la demo scema\/right keys at the right time signature.asc Description: Digital signature
Re: git bikeshedding (Re: triggers in dpkg, and dpkg maintenance)
On Sun, 24 Feb 2008, Ian Jackson wrote: But for the reasons which were discussed at length on debian-dpkg in October, this is not a good idea. Sadly I was not able to persuade Raphael. Given that many of us work on the kernel, some of us are both upstream and downstream in git, and therefore know *both* sides of the troubles and advantages of git rebase quite well... I can see why you'd have a tough time convincing anyone to change his mind about it. We will have lived it ourselves and made up our minds about it a long time ago, already... One should not rebase a git branch which has had other branches taken from it, nor should one rebase a git branch which has ever been published (at least, unless it has been published with a warning announcing that it might be rebased). Both of these practices lead to severe problems. Correct. Yet, rebasing is still routinely performed in the Linux kernel development. Indeed it should not be done for trivial reasons, as it does cause more work downstream, so the question is: what is a non-trivial reason? In the Linux kernel, we (as downstream) will usually cope with the problems it causes if it means clean history upstream. IMO, such behaviour is much better for the whole project later on. Say, in five years or so, when a different team will be working on dpkg. Or when someone is trying to chase down a bug, and has to look into the history to understand something. Many of the important subsystems in the Linux kernel community lives with this, it would not be done like that if rebasing was just a cosmetic thing. For one, merging properly rebased branches makes it a *LOT* easier to bissect, otherwise, you could find yourself bissecting a dpkg of two years ago to test a recently-merged feature whose work branches were started that long ago... In fact, it is bad enough in the kernel already, even with so much rebasing going on, because often the kernel you get while bissecting is just pure crap because people don't test enough before they send merge requests :-) If the main git branch pulls a rebased version of my triggers branch rather than the original, or if the same thing is attempted with patch and diff, then attempts to merge the main head back into the flex parser branch fail with conflicts. Raphael assured me that it would work just fine so I actually tried it, and so did Raphael later. The results were a pile of conflicts to fix up, as I had predicted. Yes. One has to just tough it up and rebase everything (and so does one's downstream). Rebase often enough in key points, and it won't be such a big pain to keep up with it. See the results of the workflow that Raphael is suggesting: http://lists.debian.org/debian-dpkg/2007/10/msg00206.html You probably want to skip the discussion and look at the transcript, about two thirds of the way down. Note that this is Raphael's message and the transcript he is presenting is what he apparently considers acceptable behaviour! Sure he does. We have a few thousand doing it in the kernel, why shouldn't he consider it acceptable? It is not done just for the kick of it. Clean history has a real benefit when it comes down to debugging and new developers joining in. Heck, some subsystems (like ACPI) have a rule where you have to *separate* all your changes into *rebased and clean* topic branches, merge them over a clean rebased branch from upstream, and submit the result of THAT merge. If you don't do it, the upstream maintainer will do it for you by force (and pick up your patches by email only, never pulling from you). OTOH, if you don't care for clean history, then the point is moot and rebasing is just a waste of everyone's effort. This can be avoided by using git properly. It already knows how to track which changes have already been merged. If you do it the right way (ie, just merge from my branch) then there are no conflicts. Everything is automatic; it just does the right thing. That would require your branch to be very clean, and would still cause issues when bissecting. If you never do bissects, and you don't care for a mess here and there in the history, indeed there is no good reason for rebasing. Of course you get a slightly messier revision history because the main dpkg revision history will then contains everything I actually did, rather than some sanitised rewrite of history. I think this is good because I want to know the actual context of a change, but Raphael thinks it is a problem because he wants a clean and pretty revision log. Yep. The real question is: which one is useful to people doing debugging and new developers joining in? Is that worth the effort? 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. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness
Re: Bug#467097: ITP: eficas -- ASter Command FIle Editor
Le dimanche 24 février 2008 à 01:15 +0100, Michael Biebl a écrit : Guus Sliepen wrote: On Sat, Feb 23, 2008 at 01:00:43PM +0100, Sylvestre Ledru wrote: I updated it: http://svn.debian.org/wsvn/pkg-scicomp/eficas/trunk/debian/control?op=filerev=0sc=0 Is it ok for do you want me to develop this more ? Description: ASter Command FIle Editor [...] The long description looks fine now, but I'd write the following short description instead: Description: graphical editor for Code Aster command files Well, ASter Command FIle Editor written backwards yields EFICAS, so I guess there is a reason why Sylvestre wrote the short description the way it is ;-) To be precise, EFICAS stands for Editeur de FIchiers de Commandes ASter which can be translated in English by ASter Command FIle Editor ;) It is a pun on the french word efficace which means efficient/efficacious. But I agree with Guss on the description, I updated it. Sylvestre signature.asc Description: Ceci est une partie de message numériquement signée
Bug#467258: Apologies
Apologies for messing around with this bug - I seem to be having a bit of finger/brain trouble -- 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 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). -Rob -- GPG key available at: http://www.robertcollins.net/keys.txt. signature.asc Description: This is a digitally signed message part
Re: How to cope with patches sanely
On Sat, 2008-02-23 at 09:08:23 -0600, Manoj Srivastava wrote: On Sat, 23 Feb 2008 08:46:03 -0500, David Nusinow [EMAIL PROTECTED] said: This argument assumes that dpkg-source -x will apply that patch stack automatically as well, which has been discussed elsewhere. Currently vapourware, no? I want to clarify this, as I've seen it mentioned several times on this thread. dpkg-source supports extracting WigPen since etch. The missing bit is source package generation (I posted a proof of concept script to convert quilted source packages to debian-dpkg [0]). regards, guillem [0] http://lists.debian.org/debian-dpkg/2008/02/msg00079.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 Sun, Feb 24, 2008 at 06:49:10PM +, Ian Jackson wrote: Jarg Sommer writes (Re: triggers in dpkg, and dpkg maintenance): Ian Jackson [EMAIL PROTECTED] wrote: 24 Oct 2007 - Raphael Hertzog asks me to `git-rebase', edit the email address in my git commit logs, and so forth, allegedly in order to make my changes easier to review. At the time I was reliably informed by git experts that published branches should not be rebased. As a rather more experienced git user it seems clear to me now that I was right to resist. There's no problem starting a new branch and rebasing this. % git branch trigger-new trigger % git rebase master trigger-new But for the reasons which were discussed at length on debian-dpkg in October, this is not a good idea. Sadly I was not able to persuade Raphael. Raphael is wrong to ask you to rebase, he's _really_ wrong about that, but *you* also are wrong to ask him to pull (aka fetch + merge). The usual way is that _you_ merge the current state of dpkg in your work so that _you_ solve the conflicts and issues, and _then_ mainline can see how it looks and look at the cleansed diff. IOW, you have to merge master, preferably in a new branch than your trigger-new one, like a master-pu-triggers or whatever, and if mainline is pleased or can read that patch (that I'm sure isn't _that_ big) they _then_ will be able to merge that branch that would just be a fast-forward. Note that they may ask you to rework this merge if they had done some further commits, but if you mkdir .git/rr-cache then git is able to use recorded images of already solved conflicts so that merging the same conflicts again and again doesn't costs you any time. Cheers, -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpnqb1X6frq0.pgp Description: PGP signature
Re: How to cope with patches sanely
On Sat, 23 Feb 2008 11:20:55 -0500, David Nusinow [EMAIL PROTECTED] said: On Sat, Feb 23, 2008 at 09:08:23AM -0600, Manoj Srivastava wrote: Now, you are trying to make me go towards a mechanism I think is inferior (a liner, dependent, and in my opinion, opaque, and somewhat shaky linear patch series) as opposed to pure, independent feature branches, for benefits I still think are dubious, so expect serious push back. Especially if for every upload I'll have to redo all the integration work of the past; ain't gonna happen. I am not trying to convince you of the error of your ways. Please desist trying to convince me of mine. No one, not me, nor anyone else in this thread that I've seen, is saying that you should abandon your sytem. What we want is a consistent method of dealing with differences from upstream. Currently, we have one giant .diff.gz, which people hack around either with patch systems or vcs's. If we switch to something other than a monolithic .diff.gz on top of a .orig.tar.gz, then we win because currently we just have a lot of chaos. So far, this is OK. The devil, though, lies in the details. No matter what you want to say about your feature branches, you *must* apply them in a linear fashion to your final source tree that you ship in the package. This is no way around it. But there is no such linearization, not in the way that quilt et al do it. The state of such integration is not maintained in the feature branches; it is in the history of the integration branch. As each feature branch was created or developed, if there were any conflicts, these conflicts were resolved in the integration branch. And the integration branch does not keep track of what changes come from which branch -- that is not its job. And it does not keep the integration patches up to date either -- that again is not its job. Details below. There are only Two use cases I care about. A) Feed each pure feature to upstream as an up to date patch against current upstream -- this is what the feature branch does. B) Have an integrated source of all features ready to compile for Debian -- and easy to keep updated with lates revisions. This is the task of the integration branch. This idea, a linear stack of changes one on top of the other, is the commonality between every one of the different means of handling changes to upstream, be they maintained by a patch system or a vcs. What we want is to stanardize this concept so that our general tools like dpkg are aware of it. This is where we start to differ. More on this below. Given what I know about your system, the only change you would have to make is that instead of integrating directly in a final branch, you generate a diff and throw that along with the diff's name in to debian/patches. I do not think you have thought it through. Let us try seeing how this will not work: Say I have have feature branches A-F. When development happens on branch A that requires some conflict resolution on the integration branch, I do the resolution, and fix up the integration branch. The fix applied depends on what order the features were merged in -- and this is not something I need to keep track of, so I do not. As more development happens, and non-overlapping changes in the same area occur, the patch would no longer apply. Other feature branches may make changes in the area; and again, make the old patch obsolete. The a new upstream version comes along, and more changes happen. By this time, the old patch will not apply even to upstream. Now rinse and repeat -- the patch you blithely threw into ./debian/patches is just dead bit by now. That's it. It could be totally automated from your current setup without much work, if that's what you want. I don't think this can be automated. However, if you think you can solve the problem, I'll stand down my objections. Love to see it demonstrated first. Indeed, the only way to redo the information in the integration branch is to start with the original upstream, from several years ago, determine which feature branch was merged in what order, what order any improvements were applied, redo the conflict resolution patches, redo the upstream version updates in the correct order, and get to the current integration branch. Heh. Good luck. This is not making you give up anything, it's about improving the base standard so everyone can get more information without learning a zillion different patch systems and vcs's. As a result, we can focus on improving the code itself instead of the process of managing the code. So, in summary, stop trying to act like you're being forced to do something that's going to hurt you. No one is taking away your toys. Words. Lets us see some code, eh? manoj -- When a man knows no this shore, other shore, or both - such a one, free from anxiety,
Re: dpkg-buildpackage now reorganizing debian/control Depends field??
David Paleino [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
Il giorno Fri, 22 Feb 2008 10:04:52 -0300
Otavio Salvador [EMAIL PROTECTED] ha scritto:
As I said, for APT, the order has meaning _always_.
apt-get install foo bar
Is completely different of
apt-get install bar foo
Could you please elaborate on this? I know for sure that Pre-Depends exists
just for the cases where order _does_ matter. But I've never had problems
in
installing packages in any order (or probably I've just been lucky).
David
I'm not sure, but I think the follwing indicates the problem.
Imagine that you have none of {foo, bar, baz, qux} installed.
Foo has Depends: baz|qux
and Bar has Depends: qux|baz
My understanding is that in that case
apt-get install foo bar
installs {foo, bar, baz} but
apt-get install bar foo
installs {foo, bar, qux}.
This is not always a major problem, and in most cases the end user will not
notice
it, but under rare cases it is theoetically possible that the dependency
chain with conflicts could cause problems. (At least it seems like that
might be the case)
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#467359: ITP: libisoburn -- libisoburn enables creation and expansion of ISO-9660 filesystems on all CD/DVD media by libburn
Package: wnpp Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org Package name: libisoburn Version: 0.1.0 Upstream Author: Vreixo Formoso [EMAIL PROTECTED], Thomas Schmitt [EMAIL PROTECTED] URL: http://libburnia-project.org License: GPL Description: ISO-9660 image manipulation wrapper library libisoburn is a frontend for libraries libburn and libisofs which enables creation and expansion of ISO-9660 filesystems on all CD/DVD media supported by libburn. This includes media like DVD+RW, which do not support multi-session management on media level and even plain disk files or block devices. (http://libburnia-project.org/wiki/Libisoburn) The xorriso ISO-9660 image manipulation program is also included. signature.asc Description: This is a digitally signed message part.
Re: Bug#467038: RFP: pytrainer -- Free Sport Training Center
Fiz, can you help me for this? Would you be interested, as upstream author, to help maintaining an *official* Debian package for your software? It would be great for me :) what files do you need? How do you want me to send you the files? best regards signature.asc Description: Esta parte del mensaje está firmada digitalmente
Re: git bikeshedding (Re: triggers in dpkg, and dpkg maintenance)
On Mon, 25 Feb 2008, Robert Collins wrote: 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). Yet, Linus himself is the one who refuses to merge anything with dirty history :-) It is a two-way knife. You choose the side of it you prefer to hold to, but you have to be careful with it *anyway*. -- 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]
Bug#467368: ITP: gmyth-upnp -- The GObject based library for using a UPnP MythTV backend
Package: wnpp Severity: wishlist Owner: Mario Limonciello [EMAIL PROTECTED] * Package name: gmyth-upnp Version : 0.7 Upstream Author : Alexsandro Jose Virginio dos Santos [EMAIL PROTECTED] Hallyson Luiz de Morais Melo [EMAIL PROTECTED] Leonardo Sobral Cunha [EMAIL PROTECTED] Rosfran Lins Borges [EMAIL PROTECTED] * URL : http://gmyth.sourceforge.net * License : GPL, Programming Lang: C Description : The GObject based library for using a UPnP MythTV backend GMyth-UPnP is a library intended to access MythTV backend functionalities from a GLib/GObject perspective via UPnP. It includes access to the program guide, recorded programs, scheduling, etc. -- System Information: Debian Release: lenny/sid APT prefers hardy-updates APT policy: (500, 'hardy-updates'), (500, 'hardy-security'), (500, 'hardy-proposed'), (500, 'hardy-backports'), (500, 'hardy') Architecture: i386 (i686) Kernel: Linux 2.6.24-8-generic (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/dash -- 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 Sun, Feb 24, 2008 at 07:46:59PM +, Henrique de Moraes Holschuh wrote: On Sun, 24 Feb 2008, Ian Jackson wrote: But for the reasons which were discussed at length on debian-dpkg in October, this is not a good idea. Sadly I was not able to persuade Raphael. Given that many of us work on the kernel, some of us are both upstream and downstream in git, and therefore know *both* sides of the troubles and advantages of git rebase quite well... I can see why you'd have a tough time convincing anyone to change his mind about it. We will have lived it ourselves and made up our minds about it a long time ago, already... For having worked quite a bit in git.git (I sent my 100th patch that should go upstream on yesterday), I can tell that it's not true. I mean, the very people designing git, are also the one using it in the kernel developpement, and look at git history, it's a suite of topic branches merges. For example, look at all the commits named 'merged branch ph/...' that would be the branches that come from my work. 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. OTOH, if you don't care for clean history, then the point is moot and rebasing is just a waste of everyone's effort. The question isn't about clean history, but a faithful one. When you rebase a branch, you pretend that you developped it on top of where you rebased it onto. Except that you didn't. This can be avoided by using git properly. It already knows how to track which changes have already been merged. If you do it the right way (ie, just merge from my branch) then there are no conflicts. Everything is automatic; it just does the right thing. That would require your branch to be very clean, and would still cause issues when bissecting. If you never do bissects, and you don't care for a mess here and there in the history, indeed there is no good reason for rebasing. You're totally on crack, git bissect works really well across merges, and has really more chances to do so, because when you rebase, you usually e.g. don't check that intermediates points build, only the top. And an intermediate point that doesn't build is _WAY_ more likely to be a PITA for bisecting than a merge point. FWIW I bisect a lot, and bisect eliminates 'dead' branches (wrt the issue you want to track down) really efficiently. 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. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpjVM63Zimu3.pgp Description: PGP signature
Debian Configuration Packaging System
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. Our system is targeted at site defaults (i.e. configuration for a university or a company), though it is useful for smaller scales as well. It has some support for multiple layers of site defaults, e.g. MIT, CSAIL (an MIT lab), and a research group within CSAIL might all use it to configure their machines [1]. The configuration package system is documented in detail at http://debathena.mit.edu/config-packages/; there are links from there to the complete source code and compiled Debian packages. The license is GPL (the same as that for CDBS itself). 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. We would appreciate any questions, comments, or feedback. -Tim Abbott and Anders Kaseorg [1] A version of config-package-dev has been in use as part of the Debathena Project (http://debathena.mit.edu/) at MIT for a few years now. Debathena is an enhanced port of Athena (MIT's cross-platform computing environment) from RHEL 4 and Solaris 10 to Debian (and Ubuntu). It's been adopted by MIT's introductory computer science class and some small clusters; but has been particularly popular for private machines whose owners want to access Athena services easily (for example, AFS and Kerberos should just work) on an existing Debian/Ubuntu machine that they are free to configure. Athena is planning to migrate to Debathena later this year. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: How to cope with patches sanely
Manoj Srivastava [EMAIL PROTECTED] writes: David Nusinow [EMAIL PROTECTED] said: No matter what you want to say about your feature branches, you *must* apply them in a linear fashion to your final source tree that you ship in the package. This is no way around it. But there is no such linearization, not in the way that quilt et al do it. The state of such integration is not maintained in the feature branches; it is in the history of the integration branch. Is this (the integration branch and its history of changes) not the linear sequence of changes that David Nusinow is asking for? And the integration branch does not keep track of what changes come from which branch -- that is not its job. Doesn't each commit message in the integration branch's history state what merge you were performing at each revision? You've previously described your workflow as one where you carefully integrate each feature branch separately into the integration branch. Do your commit messages in the integration branch not state what individual feature branch you're merging in? It seems to me that the analogue to a linear sequence of patches is the revision history of your integration branch. Granted, this doesn't give patches against a pristine upstream except from some initial state. -- \ Some mornings, it's just not worth chewing through the leather | `\ straps. -- Emo Philips | _o__) | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#467375: ITP: sakura -- a lightweight vte-based terminal emulator
Package: wnpp Severity: wishlist Owner: Andrew Lee [EMAIL PROTECTED] * Package name: sakura Version : 2.0.1 Upstream Author : David Gómez Espinosa [EMAIL PROTECTED] * URL : http://www.pleyades.net/david/sakura.php * License : (GPL) Programming Lang: (C, C++) Description : a lightweight vte-based terminal emulator Sakura is a lightweight and easy to use terminal emulator with fewer dependencies. Features: * Uses a notebook to provide several terminals in one window. * Adds a contextual menu with some basic options. No more no less. . For people that already know GNOME 2 terminal, Xfce4 terminal and are searching for a lighter but comparable replacement, sakura might be the answer. -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.24-1-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/dash
Re: Debian Configuration Packaging System
Timothy G Abbott [EMAIL PROTECTED] 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. It's generally accepted wisdom that dpkg-divert doesn't work properly with configuration files and isn't safe. I admit to have done something similar in the past, but I have noticed odd things that didn't matter for my particular use, but which meant that the support didn't work right. That's likely to be an issue for a general package. Fixing dpkg-divert to work correctly with configuration files (if possible) would probably be a good idea. -- 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
Ben Finney [EMAIL PROTECTED] writes: Manoj Srivastava [EMAIL PROTECTED] writes: But there is no such linearization, not in the way that quilt et al do it. The state of such integration is not maintained in the feature branches; it is in the history of the integration branch. Is this (the integration branch and its history of changes) not the linear sequence of changes that David Nusinow is asking for? Yes, but you don't, in the general case, completely develop some feature on a branch and then merge it only once. You do some work on one branch, merge it, do some work on another branch, merge it, do more work on the first branch and merge it again, import a new upstream and merge it into all of your branches, do some more work on the feature and merge it again I can see Manoj's point. It's not at all clear to me that there's a useful linearization of the feature branches after that sort of workflow has continued for a while. (I'm now maintaining two of my packages using only Git and feature branches without any patch system so that I can get some practical experience with this and understand the workflow better.) -- 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: git bikeshedding (Re: triggers in dpkg, and dpkg maintenance)
On Mon, 25 Feb 2008, Pierre Habouzit wrote: For having worked quite a bit in git.git (I sent my 100th patch that should go upstream on yesterday), I can tell that it's not true. I mean, the very people designing git, are also the one using it in the kernel developpement, and look at git history, it's a suite of topic branches merges. For example, look at all the commits named 'merged branch ph/...' that would be the branches that come from my work. Of course branches are merged. But some of them are *rebased* before the merge request is sent. And rebased a lot while being developed, too (I count stgit and such tools usage as rebasing). And AFAICT, the kernel works in the very same way. What gets rebased No, it doesn't work always like that. Of course, parts of the kernel development are really patch-based (stgit, quilt, quilt-on-top-of-git, etc), and get into git at the last step only, and that may well have a lot to do with it. Heck, some subsystems and maintainers get patches only over email, which is the same as a rebase from the patch submitter's PoV. OTOH, if you don't care for clean history, then the point is moot and rebasing is just a waste of everyone's effort. The question isn't about clean history, but a faithful one. When you rebase a branch, you pretend that you developped it on top of where you rebased it onto. Except that you didn't. That's a way to look at it, yes. That would require your branch to be very clean, and would still cause issues when bissecting. If you never do bissects, and you don't care for a mess here and there in the history, indeed there is no good reason for rebasing. You're totally on crack, git bissect works really well across merges, and has really more chances to do so, because when you rebase, you usually e.g. don't check that intermediates points build, only the top. And an intermediate point that doesn't build is _WAY_ more likely to be a PITA for bisecting than a merge point. Only if you are a lazy ass. Oh wait, that describes a LOT of developers out there, in Debian and Linux alike ;-) *I* checkpatch (argh), build, AND do a light runtime-test at every point of a set I am sending upstream (and that's after the heavy testing during development). I can't speak for others, though. As for me being on crack, I better explain it a bit more what I mean, apparently... 1. You start developing by branching from upstream (mainline) 2. Upstream fixes some critical bugs (maybe they are not critical for you, but they are for a third party we will call tester), after you branched from it. You either ignore any updates in mainline while working on your branch, or (more likely, for long-lived branches) you merge from mainline back into your branch a number of times during development (always without rebasing). 3. You finish your work and ask upstream to pull from you. How well will bissect work for the tester, now, if he is trying to find out something that broke with the final merge between two points where something *else* is broken in mainline? I am not sure the above is something that happens on git or dpkg, but happens all the time in the kernel. Merge of recently-rebased subsystem trees lessen that pain a lot. This is all due not to bugs in git, it is dealing just fine with the merges and branches and bissecting those. FWIW I bisect a lot, and bisect eliminates 'dead' branches (wrt the issue you want to track down) really efficiently. Yes, it does. But that is NOT enough for certain projects. And very long-lived branches are the most likely ones to cause such problems. 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. There is no excuse for accepting untested code for merges in anything that doesn't go at breakneck speed. So I have to either assume it is going to be completely tested right before the merge, or right after it. Or both ;-) If it is going to be tested by the submitter right before the merge, he might as well do it properly and test it at every step of the changeset (which is the right thing to do, if you want bissections to be easy) and at that point, rebasing can't introduce new bugs. In fact, it will let the submitter find any new latent bugs due to mainline changes *before* submitting a merge request, which is the right thing to do. If the maintainer has to test everything the submitter did after he merges news code, he might as well clean up any dirty history, because that will help testing and understanding the new code a lot.
Re: Debian Configuration Packaging System
I'll note that we wrap our dpkg-divert calls with a bunch of error-handling code that we found quite important for correctly recovering from people hitting ^C in the middle of installation (see http://debathena/config-packages/code/config-package-dev-4.2/divert.sh.in for the code). Earlier iterations that did not do this were plagued with problems whenever there were errors in installation. We also ran into a few packages which will overwrite configuration files that they manage via debconf, overwriting our symlink every time the relevant package is upgraded. But I think that's a bug in those Debian packages, since the same problem would occur for any manual changes to those configuration files as well (I think in the cases I've seen it is a failure to check whether an upgrade is occuring when generating the configuration file in postinst). What other problems have you experienced? -Tim Abbott On Sun, 24 Feb 2008, Russ Allbery wrote: Timothy G Abbott [EMAIL PROTECTED] 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. It's generally accepted wisdom that dpkg-divert doesn't work properly with configuration files and isn't safe. I admit to have done something similar in the past, but I have noticed odd things that didn't matter for my particular use, but which meant that the support didn't work right. That's likely to be an issue for a general package. Fixing dpkg-divert to work correctly with configuration files (if possible) would probably be a good idea. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: How to cope with patches sanely
On Sun, Feb 24, 2008 at 05:10:16PM -0800, Russ Allbery wrote: Ben Finney [EMAIL PROTECTED] writes: Manoj Srivastava [EMAIL PROTECTED] writes: But there is no such linearization, not in the way that quilt et al do it. The state of such integration is not maintained in the feature branches; it is in the history of the integration branch. Is this (the integration branch and its history of changes) not the linear sequence of changes that David Nusinow is asking for? Yes, but you don't, in the general case, completely develop some feature on a branch and then merge it only once. You do some work on one branch, merge it, do some work on another branch, merge it, do more work on the first branch and merge it again, import a new upstream and merge it into all of your branches, do some more work on the feature and merge it again I can see Manoj's point. It's not at all clear to me that there's a useful linearization of the feature branches after that sort of workflow has continued for a while. (I'm now maintaining two of my packages using only Git and feature branches without any patch system so that I can get some practical experience with this and understand the workflow better.) 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. - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian Configuration Packaging System
Tim Abbott [EMAIL PROTECTED] writes: We also ran into a few packages which will overwrite configuration files that they manage via debconf, overwriting our symlink every time the relevant package is upgraded. But I think that's a bug in those Debian packages, since the same problem would occur for any manual changes to those configuration files as well (I think in the cases I've seen it is a failure to check whether an upgrade is occuring when generating the configuration file in postinst). Configuration files generated by debconf may not be manually changed without running this risk, including by humans. Generally, this is documented in the file. I have several of those in packages I maintain. This is a pretty widely accepted way of dealing with configuration files, and the right way to modify those files is with debconf pre-seeding rather than by trying to overwrite the file, IMO. I don't agree that this is a bug in the package in the general case, although there may be packages that are more aggressive about overwriting than need to be. What other problems have you experienced? I've seen the diverted configuration file disappear, making it impossible to undo the diversion, and never did track down why that happened. I haven't run into any problems in cases where the diversion is never dropped, though. (But renaming the package that manages the diversions is something that dpkg-divert doesn't deal with at all well.) We're using Puppet to handle this instead of Debian packages, and I'm much happier with that solution. I wouldn't recommend doing what you're doing, but of course you may have improved the tools sufficiently that it's a good idea. :) Also, I know that most of the alternatives involve some central management system, and there are a lot of use cases that don't allow for that. -- 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
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. Well, I definitely don't think it's the only way to do things, and I've been one of the people arguing in favor of quilt and exporting to a set of patches. :) But the native Git workflow that people have previously written up for Debian packages doesn't seem to me to linearize very easily, and IMO one of the points here was to let maintainers keep using their native workflows and use the package format for interchange. Changing the workflow to allow easier export to a particular package format seems to be going the wrong direction to me. In other words, I still think a patch-based package format is a good idea and would be very valuable for a lot of what's in Debian, but I have to agree with Manoj's point, based on what I've seen so far, that converting an arbitrary Git or Arch repository for Debian package maintenance to such a package format isn't necessarily easy. -- 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 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. Well, I definitely don't think it's the only way to do things, and I've been one of the people arguing in favor of quilt and exporting to a set of patches. :) But the native Git workflow that people have previously written up for Debian packages doesn't seem to me to linearize very easily, and IMO one of the points here was to let maintainers keep using their native workflows and use the package format for interchange. Changing the workflow to allow easier export to a particular package format seems to be going the wrong direction to me. In other words, I still think a patch-based package format is a good idea and would be very valuable for a lot of what's in Debian, but I have to agree with Manoj's point, based on what I've seen so far, that converting an arbitrary Git or Arch repository for Debian package maintenance to such a package format isn't necessarily easy. Ok, that's fair. In the worst case then people who want to use this sort of workflow could stick everything in a giant diff like we do now, so nothing would be lost. - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: How to cope with patches sanely
On Mon, 25 Feb 2008 10:34:55 +1100, Ben Finney [EMAIL PROTECTED] said: Manoj Srivastava [EMAIL PROTECTED] writes: David Nusinow [EMAIL PROTECTED] said: No matter what you want to say about your feature branches, you *must* apply them in a linear fashion to your final source tree that you ship in the package. This is no way around it. But there is no such linearization, not in the way that quilt et al do it. The state of such integration is not maintained in the feature branches; it is in the history of the integration branch. Is this (the integration branch and its history of changes) not the linear sequence of changes that David Nusinow is asking for? No, it is not. I Apply a update to feature A. The comes an upstream update. Then updates on feature B, a patch that needed conflict resoution, then patches on branches C, D, and A again. Another upstream change. At this point, none of the original patches to A, B, and C apply any more -- and then come another upstream update, and all the patches get even more bent out of shape. And the integration branch does not keep track of what changes come from which branch -- that is not its job. Doesn't each commit message in the integration branch's history state what merge you were performing at each revision? It usually states what changes were made, not necessarily what feature branch I imported from. You've previously described your workflow as one where you carefully integrate each feature branch separately into the integration branch. But not in order, since not all features are developed on the same time scale, or even in sequence. And so no, all feature branches do not get integrated nicely in separate chunks and for the same upstream version either. Do your commit messages in the integration branch not state what individual feature branch you're merging in? Not usually. I describe the changes as it affects the integration branch, and sometimes I mention which branch it came from. It seems to me that the analogue to a linear sequence of patches is the revision history of your integration branch. Granted, this doesn't give patches against a pristine upstream except from some initial state. It does not even apply to the current version of upstream. If a feature branch was developed over the course of a dozen or so upstream versions, and intertwined with development on other feature branches, the integration branch might give the sequence of merges, but will not give a patch set that applies to any given upstream version, and you'll have to retrace the exact sequence of merges and upstream updates -- in other words, playing back the whole history of the package. For make, for instance, the history stretches back over a decade. manoj -- I never vote for anyone. I always vote against. W.C. Fields 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: Debian Configuration Packaging System
On Sun, 24 Feb 2008, Russ Allbery wrote: Tim Abbott [EMAIL PROTECTED] writes: We also ran into a few packages which will overwrite configuration files that they manage via debconf, overwriting our symlink every time the relevant package is upgraded. But I think that's a bug in those Debian packages, since the same problem would occur for any manual changes to those configuration files as well (I think in the cases I've seen it is a failure to check whether an upgrade is occuring when generating the configuration file in postinst). Configuration files generated by debconf may not be manually changed without running this risk, including by humans. Generally, this is documented in the file. I have several of those in packages I maintain. This is a pretty widely accepted way of dealing with configuration files, and the right way to modify those files is with debconf pre-seeding rather than by trying to overwrite the file, IMO. Many such files have configuration options other than those managed by debconf (/etc/krb5.conf would be a good example). For those files, pre-seeding debconf doesn't suffice. What other problems have you experienced? I've seen the diverted configuration file disappear, making it impossible to undo the diversion, and never did track down why that happened. I haven't run into any problems in cases where the diversion is never dropped, though. (But renaming the package that manages the diversions is something that dpkg-divert doesn't deal with at all well.) Renaming a package requires no special effort in our system (the new package and the old package will conflict because they divert the same file, and the old package will remove the diversion on prerm because it knows it is being removed, and then the new package will install the new diversion on postinst). -Tim Abbott -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: How to cope with patches sanely
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. Well, I definitely don't think it's the only way to do things, and I've been one of the people arguing in favor of quilt and exporting to a set of patches. :) But the native Git workflow that people have previously written up for Debian packages doesn't seem to me to linearize very easily, and IMO one of the points here was to let maintainers keep using their native workflows and use the package format for interchange. Changing the workflow to allow easier export to a particular package format seems to be going the wrong direction to me. In other words, I still think a patch-based package format is a good idea and would be very valuable for a lot of what's in Debian, but I have to agree with Manoj's point, based on what I've seen so far, that converting an arbitrary Git or Arch repository for Debian package maintenance to such a package format isn't necessarily easy. Ok, that's fair. In the worst case then people who want to use this sort of workflow could stick everything in a giant diff like we do now, so nothing would be lost. Or have dpkg understand not just quilt, but git. I mean, if we are making dpkg understand quilt-as-a-version-control system, why not also have it grok a modern SCM like git? (I know that trying to get it to understand arch is a lost cause). Would joeyh's efforts to get dpkg v3 format be a got repo make a difference here? manoj -- Freedom begins when you tell Mrs. Grundy to go fly a kite. 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: Debian Configuration Packaging System
Tim Abbott [EMAIL PROTECTED] writes: On Sun, 24 Feb 2008, Russ Allbery wrote: Configuration files generated by debconf may not be manually changed without running this risk, including by humans. Generally, this is documented in the file. I have several of those in packages I maintain. This is a pretty widely accepted way of dealing with configuration files, and the right way to modify those files is with debconf pre-seeding rather than by trying to overwrite the file, IMO. Many such files have configuration options other than those managed by debconf (/etc/krb5.conf would be a good example). For those files, pre-seeding debconf doesn't suffice. And krb5.conf is not a configuration file managed in the way that you describe for exactly that reason. It uses a conservative approach, only installing a file based on debconf prompts if the file doesn't already exist and otherwise trying to do automated updates of only the configured data where applicable. (You can also make the file a symlink to disable all automated modification.) 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. -- 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: Practical solutions to: the new style mass tirage of bugs
On Sun, 24 Feb 2008, Stefano Zacchiroli wrote: On Sat, Feb 23, 2008 at 01:03:01PM -0800, Don Armstrong wrote: If there are sets of usertags which are in common use by a reasonable number of diverse packages, and are something that would normally be put on the [EMAIL PROTECTED] user (that is to say, make them visible by default) then file a bug against bugs.debian.org askiing for that tag to be made a real tag. That's the best way to standardize usertags which are currently not bts-wide tags. Ack on the general principle. However, the need which was pointed out to seemed to me more than a tag: in my head it was distilled as priority, as available in other bug tracking systems. This is something that can be encoded with usertags, but such an encoding does not have good properties such as mutual exclusion of alternative priorities. It almost sounds like you want a user setable severity-like field. That could be implemented, but the problem is that it's far less flexible than usertags because it would only have a single value. In fact, assuming the assignment to usercategories was done properly, it wouldn't matter if a bug had multiple priority tags, as a bug that had the higest tag would be separated from the other tags even if it still had a lower tag. See http://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=debbugs;[EMAIL PROTECTED] for an example of my segregation of the debbugs package. Don Armstrong -- To steal ideas from one person is plagiarism; to steal from many is research. -- Steven Wright http://www.donarmstrong.com http://rzlab.ucr.edu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: How to cope with patches sanely
Hi, I think one of the differences that patch series mechanism has wrt to new development, either in a feature or upstream, is that it requires updates to the integration work doe every single upload. It also requires a strict ordering between each feature, making it harder to compile and test each feature independently. It is nice that quilt helps keep the integration patch up to date; but this is extra work I am glad not to have to do. An integration branch does the integration once, and does not bother to explicitly keep the integration patch updated for every upload -- but it does keep each feature branch up to date, and the integration branch has a current set of features. This is reduced work load for each change; at the expense of stashing integration knowledge deep in the entrails of the integration branch. I like the reduced work for each upload, and since it satisfies the use cases of being able to present upstream with a pure feature changeset; to be able to rapidly compare any feature branch against each other or upstream, and being able to maintain an integrated source tree for Debian packages, I am happy not to keep integration patches up to date. Now, if there is indeed a mechanism that can automatically keep up the integration patches and convert feature branches to an integrated source tree via a patch series, I'll gladly eat crow and try to convert over. But I still want to keep pure feature branches, and I do not want to have to worry about integration all over again at every upload. Unless new information comes up on this thread, I am done. manoj -- Reinhart was never his mother's favorite -- and he was an only child. Thomas Berger 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: news from mips?
Le Fri, Feb 22, 2008 at 09:55:08AM +0100, Florian Lohoff a écrit : The mipsel buildd rem has a new disk and the buildd dir will be moved which will speed it up a lot (PIO vs DMA) Dear Florian, this is good news: we can see mipsel getting better on the buildd stats: http://buildd.debian.org/stats/graph2-week-big.png However, it does not give much help for packages to migrate in testing: the queue on the mips buildd is still growing. Is there any plan to solve this problem ? Some packages are blocked for almost a month, and judging from the absence of buildd logs for mips(el) for some packages that recently migrated, it seems that the best way to deal with the problem is to upload binary built elsewnere… I know that it is not pleasant to hear, but again: for the package I care about and that are waiting to be built on mips, I have never had any evidence that they have users on this port. I would be glad to be proven wrong, but in the meantime, we are delaying service to our users for no benefit at all. Have a nice day, -- Charles Plessy http://charles.plessy.org Wakō, Saitama, Japan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Practical solutions to: the new style mass tirage of bugs
On 24/02/08 at 20:41 +0100, Stefano Zacchiroli wrote: On Sat, Feb 23, 2008 at 01:03:01PM -0800, Don Armstrong wrote: If there are sets of usertags which are in common use by a reasonable number of diverse packages, and are something that would normally be put on the [EMAIL PROTECTED] user (that is to say, make them visible by default) then file a bug against bugs.debian.org askiing for that tag to be made a real tag. That's the best way to standardize usertags which are currently not bts-wide tags. Ack on the general principle. However, the need which was pointed out to seemed to me more than a tag: in my head it was distilled as priority, as available in other bug tracking systems. This is something that can be encoded with usertags, but such an encoding does not have good properties such as mutual exclusion of alternative priorities. For many users of other bug tracking systems such as bugzilla, the meaning of priority vs severity is totally unclear. I don't think that it would be a good idea to impose such a thing to all packages by default. As Don pointed, it is relatively easy to emulate priorities using usertags and usercategories. Maybe the BTS could help by providing other sorting orders by default (so viewing priorities would simply be a matter of adding sort=priorities to pkgreport's URL), and/or by providing more examples of custom sorts. -- | Lucas Nussbaum | [EMAIL PROTECTED] http://www.lucas-nussbaum.net/ | | jabber: [EMAIL PROTECTED] GPG: 1024D/023B3F4F | signature.asc Description: Digital signature
Re: Bits from the DPL: FTP assistants, marketing team, init scripts, elections
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? -- .''`. 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 plan to be spontaneous tomorrow. digital_signature_gpg.asc Description: Digital signature (see http://martin-krafft.net/gpg/)
Re: How to cope with patches sanely
also sprach Manoj Srivastava [EMAIL PROTECTED] [2008.02.22.1627 +0100]: I am not sure you have understood feature branches. They are independent, no matter what the overlap. Each feature branch tracks one feature against upstream, no matter how the other features work. The overlap management is done in the integration branch. This is significantly different from a quilt series, as others have already mentioned in this thread,which is a dependent series of linearized patches; and a change in an earlier feature impacts all subsequent patches (and quilt is good at automating the handling of that impact). [[duplicated so this can be archived on the vcs-package mailing list as well]] well, I know what feature branches are but I suppose I jumped the gun. They are independent until you integrate them. But you will integrate them, thus I tend to think of them as interdependent from the start. Anyway, we're not talking about developing with quilt. We are talking about converting feature branches to quilt patches for the sake of representation in the source package. I don't see why you would oppose to that at all, to be honest. Or the patch manager does integration. *Shrug*. Someone has to do integration sometime. That is the nature of the beast. The trick is to do it once, and never have to think about it again. ... except when one feature needs to change and then conflicts with another feature on re-integration. B) Development happens on the feature branch. [...] 2) Development on one of the branches conflicts with one or more other features. Here, the human has to figure out the difference on the integration branch -- once. No, every time you do development on the branch. And every time, you have to remember which branch dependended/conflicted on the feature branch you're currently working on, or figure it out by trial and error. I don't consider this efficient. This is work that a computer should be doing. -- .''`. 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 windoze 98: n. useless extension to a minor patch release for 32-bit extensions and a graphical shell for a 16-bit patch to an 8-bit operating system originally coded for a 4-bit microprocessor, written by a 2-bit company that can't stand for 1 bit of competition. 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 su, 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? We had a chicken[1]. We spent years actively getting rid of it. [1] Technically speaking it was a penguin. But it was a youthful penguin, rebelling against its genetic heritage. -- 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, 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. LCA2009 has a tasmanian devil pretending to be penguin [²]. [²] https://linux.conf.au/ signature.asc Description: Digital signature
Re: Bits from the DPL: FTP assistants, marketing team, init scripts, elections
On Mon, 25 Feb 2008 09:07:20 +0200, Lars Wirzenius [EMAIL PROTECTED] said: On su, 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? We had a chicken[1]. We spent years actively getting rid of it. I loved the chicken. I had a character. [1] Technically speaking it was a penguin. But it was a youthful penguin, rebelling against its genetic heritage. Youthful, but with taste. I thought it gave us a better logo than the somewhat blah swirl. But I lost that vote manoj -- If only you knew she loved you, you could face the uncertainty of whether you love her. 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: How to cope with patches sanely
On Sun, 24 Feb 2008 11:04:21 +0100, martin f krafft [EMAIL PROTECTED] said: also sprach Manoj Srivastava [EMAIL PROTECTED] [2008.02.22.1627 +0100]: I am not sure you have understood feature branches. They are independent, no matter what the overlap. Each feature branch tracks one feature against upstream, no matter how the other features work. The overlap management is done in the integration branch. This is significantly different from a quilt series, as others have already mentioned in this thread,which is a dependent series of linearized patches; and a change in an earlier feature impacts all subsequent patches (and quilt is good at automating the handling of that impact). [[duplicated so this can be archived on the vcs-package mailing list as well]] well, I know what feature branches are but I suppose I jumped the gun. They are independent until you integrate them. But you will integrate them, thus I tend to think of them as interdependent from the start. You have a strange definition of interdependent. The majority of my feature branches are really orthogonal; seldom on integration there is no conflict; so it is hard for me to think of them as somehow inter dependent. Sure, there are overlapping changes, sometimes, but these are mostly one time resolution issues. Anyway, we're not talking about developing with quilt. We are talking about converting feature branches to quilt patches for the sake of representation in the source package. I don't see why you would oppose to that at all, to be honest. 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. Or the patch manager does integration. *Shrug*. Someone has to do integration sometime. That is the nature of the beast. The trick is to do it once, and never have to think about it again. ... except when one feature needs to change and then conflicts with another feature on re-integration. 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. B) Development happens on the feature branch. [...] 2) Development on one of the branches conflicts with one or more other features. Here, the human has to figure out the difference on the integration branch -- once. No, every time you do development on the branch. And every time, you have to remember which branch dependended/conflicted on the feature branch you're currently working on, or figure it out by trial and error. I don't consider this efficient. This is work that a computer should be doing. Strange. In all my years of using feature branches, I have never had to consider which branch depended on what. So no, I don't think I _have_ to remember any such thing; trust me, I would have noticed. I have 30+ packages, and have been using feature branches since early this decade. If you have a whole slew of features that depend on other features, then your feature set is very different from ones I have encountered. Dependent features do require more work; but not as much, in my opinion, as using quilt or dpatch; but your mileage may vary. For the most part, I just develop on each branch independently. I compile, test, hack, compile, on each individual featre branch. And never ever worry about what the other feature branches are like, while doing so. Once in a blue moon (more or less) I have to deconflict the integration branch; but mostly those are swiftly resolved issues. And once resoved, I tend to forget about them too. All this worrying about branch conflicts seem to be more the realm of quilt and other patch series mechanisms; which is mostly my reason to dislike them. manoj -- (It is an old Debian tradition to leave at least twice a year ...) Sven Rudolph 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: How to cope with patches sanely
On Sun, 24 Feb 2008, Charles Plessy wrote: Le Sun, Feb 24, 2008 at 10:47:05AM +0100, Raphael Hertzog a écrit : - When modifying a package that uses dpatch, quilt or simple-patchsys, developpers have to find out by themselves if the target for patching the sources is patch, apply-patches or apply-dpatches. Once the new dpkg-source format is in standard use, those rules disappear completely... because they are no more needed during build. I must have missed something. I thought that the new format was to keep the debian directory in a tar.gz format. With this format, people who want to modify upstream sources will have to use a patch system. What is the plan to make the patch targets in debian/rules unneeded? If the patch are applied by default, there's no need to apply them again at build time. Then quilt/dpatch tools will only be used by the packager to modify/updated its patch serie during maintenance but the tool won't be needed during recompilation (and thus doesn't need to be in Build-Depends). 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: How to cope with patches sanely
Hi, On Sun, 24 Feb 2008, Manoj Srivastava wrote: I like the reduced work for each upload, and since it satisfies the use cases of being able to present upstream with a pure feature changeset; It doesn't satisfy it completely. You can always generate a patch for a pure feature changeset but you can't guarantee that all those feature patches apply at the same time. Let's say you have 5 feature patches, the upstream maintainer wants to integrate 3 of them. How can you submit 3 patches that would apply one after the other? You have to redo some of your integration work that you already did. That said, even with a pure quilt set of patches, you can't guarantee it either. If one of the wanted patch has some overlap with one of the non-wanted ones... All in all, I think we do all exagerate the problems. In my experience, most of the patches applied to a Debian package are relatively independant of each other and inter-relationships is the exception, not the rule. But if we can come up with a solution that handles perfectly inter-dependant patches, that would still be great. :-) 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]
Accepted libconfig-general-perl 2.37-2 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Wed, 20 Feb 2008 12:31:04 +0100 Source: libconfig-general-perl Binary: libconfig-general-perl Architecture: source all Version: 2.37-2 Distribution: unstable Urgency: low Maintainer: Francesco Cecconi [EMAIL PROTECTED] Changed-By: Francesco Cecconi [EMAIL PROTECTED] Description: libconfig-general-perl - Generic Configuration Module Changes: libconfig-general-perl (2.37-2) unstable; urgency=low . * updated Standard Version to 3.7.3. * [debian/rules]: fix for perl5 empty directory. * [debian/compat]: updated to level 5. Files: fdf83911bf972a7c23ececcd4b01f6ed 721 perl optional libconfig-general-perl_2.37-2.dsc 4db8633ab06f4a083eb49e78b3b18059 3334 perl optional libconfig-general-perl_2.37-2.diff.gz 638052b308809bce588e745a689340b8 66264 perl optional libconfig-general-perl_2.37-2_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHwSrQs3U+TVFLPnwRAgRyAJwPoJ8sk2NxlT5ZRRGCWhk8lgyZawCfTWFM vvlnUe8bnDvKQcon1cpFi3I= =te/E -END PGP SIGNATURE- Accepted: libconfig-general-perl_2.37-2.diff.gz to pool/main/libc/libconfig-general-perl/libconfig-general-perl_2.37-2.diff.gz libconfig-general-perl_2.37-2.dsc to pool/main/libc/libconfig-general-perl/libconfig-general-perl_2.37-2.dsc libconfig-general-perl_2.37-2_all.deb to pool/main/libc/libconfig-general-perl/libconfig-general-perl_2.37-2_all.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted octave2.1-forge 2006.03.17+dfsg1-6 (source amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Sat, 23 Feb 2008 22:08:45 +0100 Source: octave2.1-forge Binary: octave2.1-forge Architecture: source amd64 Version: 2006.03.17+dfsg1-6 Distribution: unstable Urgency: low Maintainer: Debian Octave Group [EMAIL PROTECTED] Changed-By: Rafael Laboissiere [EMAIL PROTECTED] Description: octave2.1-forge - Contributed functions from the GNU Octave Repository Closes: 417494 Changes: octave2.1-forge (2006.03.17+dfsg1-6) unstable; urgency=low . * debian/control: Removed Cyril Brulebois from the list of Uploaders, at his request * debian/patches/g++4.3-fixes.patch: Make the package build with GCC 4.3 (closes: #417494) * debian/patches/manpage-comments.patch: Fix comment macro in mex.1 manpage Files: 6a243c531d30510540f6da1fd30f60f8 1294 math optional octave2.1-forge_2006.03.17+dfsg1-6.dsc 69f9544d10fe04e0593ba56c7f12677a 20352 math optional octave2.1-forge_2006.03.17+dfsg1-6.diff.gz 10480437fcaea4dbba3e0a3eae14c36f 2766478 math optional octave2.1-forge_2006.03.17+dfsg1-6_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQFHwS/hk3oga0pdcv4RAkDRAJ0b9usTOEa82iE0Vmq2HoxbJPnmcACeLLnm Jqb8f0ikhkjAA/Oku/e1FF4= =l5ut -END PGP SIGNATURE- Accepted: octave2.1-forge_2006.03.17+dfsg1-6.diff.gz to pool/main/o/octave2.1-forge/octave2.1-forge_2006.03.17+dfsg1-6.diff.gz octave2.1-forge_2006.03.17+dfsg1-6.dsc to pool/main/o/octave2.1-forge/octave2.1-forge_2006.03.17+dfsg1-6.dsc octave2.1-forge_2006.03.17+dfsg1-6_amd64.deb to pool/main/o/octave2.1-forge/octave2.1-forge_2006.03.17+dfsg1-6_amd64.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted tracker 0.6.4-3 (source all i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Sun, 24 Feb 2008 02:36:23 +0100 Source: tracker Binary: tracker libtrackerclient0 libtrackerclient-dev libtracker-gtk0 libtracker-gtk-dev tracker-utils tracker-search-tool libdeskbar-tracker tracker-dbg Architecture: source all i386 Version: 0.6.4-3 Distribution: unstable Urgency: low Maintainer: Michael Biebl [EMAIL PROTECTED] Changed-By: Michael Biebl [EMAIL PROTECTED] Description: libdeskbar-tracker - metadata database, indexer and search tool - deskbar-applet plugi libtracker-gtk-dev - GTK+ widgets for apps that use tracker - development files libtracker-gtk0 - GTK+ widgets for apps that use tracker libtrackerclient-dev - metadata database, indexer and search tool - development files libtrackerclient0 - metadata database, indexer and search tool - library tracker- metadata database, indexer and search tool tracker-dbg - metadata database, indexer and search tool - debugging symbols tracker-search-tool - metadata database, indexer and search tool - GNOME frontend tracker-utils - metadata database, indexer and search tool - commandline tools Closes: 438959 Changes: tracker (0.6.4-3) unstable; urgency=low . * debian/control - Replace Build-Depends python-central with python-support. - Remove X[BS]-Python-Version fields. * debian/rules - Add call to dh_pysupport passing it the path of the deskbar-applet modules directory. - Remove dh_pycentral. * debian/tracker-search-tool.menu - Add a menu file for tracker-search-tool. Closes: #438959 Files: fd637d94a37396ff3b816c820a6266db 1411 utils optional tracker_0.6.4-3.dsc 127afa2ea5334d6c070c8a568148486a 10832 utils optional tracker_0.6.4-3.diff.gz 0796c8be09dc17b4334722cfd0b1f3cb 41808 utils optional libdeskbar-tracker_0.6.4-3_all.deb 58cf94175c62e78f7d2c0c1811714b72 409682 utils optional tracker_0.6.4-3_i386.deb e0293401815a5313155fd0448f3a0299 46726 libs optional libtrackerclient0_0.6.4-3_i386.deb 84bc1c30b103a8beebf073207921a2b2 51908 libdevel optional libtrackerclient-dev_0.6.4-3_i386.deb b11f9b630518b32dff245ced3edb99f9 52272 libs optional libtracker-gtk0_0.6.4-3_i386.deb ec10b51ef092cf7ab70e8aa406161c3e 53862 libdevel optional libtracker-gtk-dev_0.6.4-3_i386.deb 9be6842691858ead8892bc860bcb2a55 53390 utils optional tracker-utils_0.6.4-3_i386.deb bc74036ed2132727b6317ea924074dc1 118002 gnome optional tracker-search-tool_0.6.4-3_i386.deb 9576c1766595df2f84fa82fe91ff353b 723222 utils extra tracker-dbg_0.6.4-3_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHwNJFh7PER70FhVQRAktUAJ9PdHAGBR2EadsSB2kfzBC54TnS1ACgzmPQ CJYQvte8RWXjcCd7ymb9hH8= =mthN -END PGP SIGNATURE- Accepted: libdeskbar-tracker_0.6.4-3_all.deb to pool/main/t/tracker/libdeskbar-tracker_0.6.4-3_all.deb libtracker-gtk-dev_0.6.4-3_i386.deb to pool/main/t/tracker/libtracker-gtk-dev_0.6.4-3_i386.deb libtracker-gtk0_0.6.4-3_i386.deb to pool/main/t/tracker/libtracker-gtk0_0.6.4-3_i386.deb libtrackerclient-dev_0.6.4-3_i386.deb to pool/main/t/tracker/libtrackerclient-dev_0.6.4-3_i386.deb libtrackerclient0_0.6.4-3_i386.deb to pool/main/t/tracker/libtrackerclient0_0.6.4-3_i386.deb tracker-dbg_0.6.4-3_i386.deb to pool/main/t/tracker/tracker-dbg_0.6.4-3_i386.deb tracker-search-tool_0.6.4-3_i386.deb to pool/main/t/tracker/tracker-search-tool_0.6.4-3_i386.deb tracker-utils_0.6.4-3_i386.deb to pool/main/t/tracker/tracker-utils_0.6.4-3_i386.deb tracker_0.6.4-3.diff.gz to pool/main/t/tracker/tracker_0.6.4-3.diff.gz tracker_0.6.4-3.dsc to pool/main/t/tracker/tracker_0.6.4-3.dsc tracker_0.6.4-3_i386.deb to pool/main/t/tracker/tracker_0.6.4-3_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted cdebootstrap 0.4.6 (source amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Sun, 24 Feb 2008 09:45:29 + Source: cdebootstrap Binary: cdebootstrap cdebootstrap-static cdebootstrap-udeb Architecture: source amd64 Version: 0.4.6 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) Closes: 325487 435254 Changes: cdebootstrap (0.4.6) unstable; urgency=low . * Redo mirror parsing. (closes: #325487) * Allocate command buffer dynamic. (closes: #435254) Files: c231405c00c8656064cd27fa3c1bf0fc 637 admin optional cdebootstrap_0.4.6.dsc 154e67064631905644a1ff97e661d636 139947 admin optional cdebootstrap_0.4.6.tar.gz d6f073909f09198e8c7129b926b39657 30852 admin optional cdebootstrap_0.4.6_amd64.deb 41b705e4ea0c16eeeb10ca8f37537d30 595214 admin optional cdebootstrap-static_0.4.6_amd64.deb 44334930951695d71e522c8abf54838d 21054 debian-installer optional cdebootstrap-udeb_0.4.6_amd64.udeb Package-Type: udeb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iEYEARECAAYFAkfBPc0ACgkQxWtQqFixGB47jgCghes5aZfChTfITWFHXULA1lbP /ykAn0dNs9TxGO76dbmtsAkK8ZHZLiY6 =s6dd -END PGP SIGNATURE- Accepted: cdebootstrap-static_0.4.6_amd64.deb to pool/main/c/cdebootstrap/cdebootstrap-static_0.4.6_amd64.deb cdebootstrap-udeb_0.4.6_amd64.udeb to pool/main/c/cdebootstrap/cdebootstrap-udeb_0.4.6_amd64.udeb cdebootstrap_0.4.6.dsc to pool/main/c/cdebootstrap/cdebootstrap_0.4.6.dsc cdebootstrap_0.4.6.tar.gz to pool/main/c/cdebootstrap/cdebootstrap_0.4.6.tar.gz cdebootstrap_0.4.6_amd64.deb to pool/main/c/cdebootstrap/cdebootstrap_0.4.6_amd64.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted win32-loader 0.6.2 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Sun, 24 Feb 2008 11:29:54 +0100 Source: win32-loader Binary: win32-loader Architecture: source all Version: 0.6.2 Distribution: unstable Urgency: low Maintainer: Debian Install System Team [EMAIL PROTECTED] Changed-By: Robert Millan [EMAIL PROTECTED] Description: win32-loader - Debian-Installer loader for win32 Closes: 441379 464972 466333 Changes: win32-loader (0.6.2) unstable; urgency=low . * s/XFCE/Xfce/g. (Closes: #466333) * Fix bcdedit load in 64-bit Vista. Thanks Amir Szekely for the hints. (Closes: #441379) . [ Updated translations ] * Traditional Chinese (zh_TW.po) by Tetralet (Closes: #464972) Files: 92ec2302928da723ffb8236a3d7e3647 762 utils extra win32-loader_0.6.2.dsc 5cb24dcdf61143e21a395204c216554c 117770 utils extra win32-loader_0.6.2.tar.gz ffce3573947bdab707f76c80968e3c63 64 utils extra win32-loader_0.6.2_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHwUdOC19io6rUCv8RAmJyAJoDPNEMkCIf17myqHi9pUhGi6/xWwCfREE/ 0aeeuAikliv5djkabxamBNs= =jTd5 -END PGP SIGNATURE- Accepted: win32-loader_0.6.2.dsc to pool/main/w/win32-loader/win32-loader_0.6.2.dsc win32-loader_0.6.2.tar.gz to pool/main/w/win32-loader/win32-loader_0.6.2.tar.gz win32-loader_0.6.2_all.deb to pool/main/w/win32-loader/win32-loader_0.6.2_all.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted python-scipy 0.6.0-8 (source amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Sat, 23 Feb 2008 01:21:51 +0100 Source: python-scipy Binary: python-scipy Architecture: source amd64 Version: 0.6.0-8 Distribution: unstable Urgency: low Maintainer: Debian Python Modules Team [EMAIL PROTECTED] Changed-By: Ondrej Certik [EMAIL PROTECTED] Description: python-scipy - scientific tools for Python Closes: 466868 Changes: python-scipy (0.6.0-8) unstable; urgency=low . * Build depend on libsuitesparse (= 3.1.0-3) * Build depends fixed to use gfortran based lapack and blas (Closes: #466868) Files: 0b3cea19029b4b5a32cc30272838957e 1239 python extra python-scipy_0.6.0-8.dsc 155d57e564e197b23d1a0fed78ee3862 7927 python extra python-scipy_0.6.0-8.diff.gz a19122c8f01dd9c8a81a6494cb2b9516 7234004 python extra python-scipy_0.6.0-8_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHwUVcKQ++Uu6gdgkRAsjVAJ0Uxg6KpNMIkhdMtsJZ8Hy05ccUDACfRc/v m8nmRbM+CL634JHOtmmMX8A= =WyXC -END PGP SIGNATURE- Accepted: python-scipy_0.6.0-8.diff.gz to pool/main/p/python-scipy/python-scipy_0.6.0-8.diff.gz python-scipy_0.6.0-8.dsc to pool/main/p/python-scipy/python-scipy_0.6.0-8.dsc python-scipy_0.6.0-8_amd64.deb to pool/main/p/python-scipy/python-scipy_0.6.0-8_amd64.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted samizdat 0.6.0.20080224-1 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Sun, 24 Feb 2008 12:43:38 +0200 Source: samizdat Binary: samizdat libsamizdat-ruby libsamizdat-ruby1.8 Architecture: source all Version: 0.6.0.20080224-1 Distribution: experimental Urgency: low Maintainer: Dmitry Borodaenko [EMAIL PROTECTED] Changed-By: Dmitry Borodaenko [EMAIL PROTECTED] Description: libsamizdat-ruby - Samizdat module for Ruby libsamizdat-ruby1.8 - Samizdat module for Ruby 1.8 samizdat - Collaboration and open publishing engine Changes: samizdat (0.6.0.20080224-1) experimental; urgency=low . * New upstream snapshot 2008-02-24: - minor fixes and optimizations - database schema changed (index added). Files: a79771dca4f31140d4fef7bf54885241 659 web optional samizdat_0.6.0.20080224-1.dsc d5d0d4362009e66e75e30469dce7aa4c 227200 web optional samizdat_0.6.0.20080224.orig.tar.gz 3d354ac47d81e3b3f93c38449b61edf2 7870 web optional samizdat_0.6.0.20080224-1.diff.gz 819391cb3cc9556f7c70db1c976c951d 177620 web optional samizdat_0.6.0.20080224-1_all.deb 836d437f9fffa01a4ab74e240348f985 25038 interpreters optional libsamizdat-ruby_0.6.0.20080224-1_all.deb 099b1f616db6d10e80d50bb4224ba676 39490 interpreters optional libsamizdat-ruby1.8_0.6.0.20080224-1_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iEYEARECAAYFAkfBSsAACgkQxhqJXoXuPg4sdQCdHsIF9USCQV4kWhGHbKeFE0E9 pzwAn39l5KwPsVp/3X1PAaXg4DE/OEko =oZ+Z -END PGP SIGNATURE- Accepted: libsamizdat-ruby1.8_0.6.0.20080224-1_all.deb to pool/main/s/samizdat/libsamizdat-ruby1.8_0.6.0.20080224-1_all.deb libsamizdat-ruby_0.6.0.20080224-1_all.deb to pool/main/s/samizdat/libsamizdat-ruby_0.6.0.20080224-1_all.deb samizdat_0.6.0.20080224-1.diff.gz to pool/main/s/samizdat/samizdat_0.6.0.20080224-1.diff.gz samizdat_0.6.0.20080224-1.dsc to pool/main/s/samizdat/samizdat_0.6.0.20080224-1.dsc samizdat_0.6.0.20080224-1_all.deb to pool/main/s/samizdat/samizdat_0.6.0.20080224-1_all.deb samizdat_0.6.0.20080224.orig.tar.gz to pool/main/s/samizdat/samizdat_0.6.0.20080224.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted mesa 7.0.3~rc2-1 (source all i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Sun, 24 Feb 2008 10:22:54 +0100 Source: mesa Binary: libgl1-mesa-swx11 libgl1-mesa-swx11-dbg libgl1-mesa-swx11-i686 libgl1-mesa-swx11-dev libgl1-mesa-glx libgl1-mesa-glx-dbg libgl1-mesa-dri libgl1-mesa-dri-dbg libgl1-mesa-dev mesa-common-dev libosmesa6 libosmesa6-dev libglu1-mesa libglu1-mesa-dev libglw1-mesa libglw1-mesa-dev mesa-swx11-source mesa-utils Architecture: source all i386 Version: 7.0.3~rc2-1 Distribution: unstable Urgency: low Maintainer: Debian X Strike Force [EMAIL PROTECTED] Changed-By: Julien Cristau [EMAIL PROTECTED] Description: libgl1-mesa-dev - A free implementation of the OpenGL API -- GLX development files libgl1-mesa-dri - A free implementation of the OpenGL API -- DRI modules libgl1-mesa-dri-dbg - Debugging symbols for the Mesa DRI modules libgl1-mesa-glx - A free implementation of the OpenGL API -- GLX runtime libgl1-mesa-glx-dbg - Debugging symbols for the Mesa GLX runtime libgl1-mesa-swx11 - A free implementation of the OpenGL API -- runtime libgl1-mesa-swx11-dbg - A free implementation of the OpenGL API -- debugging symbols libgl1-mesa-swx11-dev - A free implementation of the OpenGL API -- development files libgl1-mesa-swx11-i686 - Mesa OpenGL runtime [i686 optimized] libglu1-mesa - The OpenGL utility library (GLU) libglu1-mesa-dev - The OpenGL utility library -- development files libglw1-mesa - A free implementation of the OpenGL API -- runtime libglw1-mesa-dev - A free implementation of the OpenGL API -- development files libosmesa6 - Mesa Off-screen rendering extension libosmesa6-dev - Mesa Off-screen rendering extension -- development files mesa-common-dev - Developer documentation for Mesa mesa-swx11-source - Mesa software rasteriser source -- development files mesa-utils - Miscellaneous Mesa GL utilities Closes: 408679 Changes: mesa (7.0.3~rc2-1) unstable; urgency=low . * New upstream release candidate. + enable user-defined clip planes for R300 (closes: #408679) + 03_optional-progs-and-install.patch: partly applied upstream, fixed up * Stop building with -O0 on hppa. Bug #451047 should be fixed in recent gcc versions. Files: fb5d8d0b16a860d99c19b37af98b615b 1429 graphics optional mesa_7.0.3~rc2-1.dsc ae381144732f27cc5952dac7ae55ad7e 6544088 graphics optional mesa_7.0.3~rc2.orig.tar.gz 1507f2511c74b61f4896532ef5108242 245412 graphics optional mesa_7.0.3~rc2-1.diff.gz 3e66639ed5a55764c75f9ad16ac7 25296 libdevel optional libgl1-mesa-dev_7.0.3~rc2-1_all.deb 063001f99b3cffa52806bd12fd172fbc 182716 libdevel optional mesa-common-dev_7.0.3~rc2-1_all.deb 44d590257a9b8ccaf6183c2c5057d488 1548568 libdevel optional mesa-swx11-source_7.0.3~rc2-1_all.deb 871430cbf166924d76d3740a52d50721 899348 libs extra libgl1-mesa-swx11_7.0.3~rc2-1_i386.deb be498bb814a6cd52bfd110bfc1c65376 5158620 libdevel extra libgl1-mesa-swx11-dbg_7.0.3~rc2-1_i386.deb 5f9336bde8c2a6dadd9666d7eff35191 896930 libs extra libgl1-mesa-swx11-i686_7.0.3~rc2-1_i386.deb 6f6d58e13ef6b5d9fee90b4b118a6f14 1015086 libdevel extra libgl1-mesa-swx11-dev_7.0.3~rc2-1_i386.deb 663080a210363cea4fc403d1caf3e94c 148514 libs optional libgl1-mesa-glx_7.0.3~rc2-1_i386.deb 7ecf9d402b76f45071c565f56404c431 484064 libdevel extra libgl1-mesa-glx-dbg_7.0.3~rc2-1_i386.deb b3d1d0cfa2479f7c76bdb1362444fe88 13111878 libs optional libgl1-mesa-dri_7.0.3~rc2-1_i386.deb 1a36aec947532c68302a7a5e36f84a5c 85038872 libdevel extra libgl1-mesa-dri-dbg_7.0.3~rc2-1_i386.deb da6a5552111fd38b55b2b74ad1f4e3a3 2371210 libs optional libosmesa6_7.0.3~rc2-1_i386.deb 43b818f09a0d246b86e233c9399b7114 2711518 libdevel optional libosmesa6-dev_7.0.3~rc2-1_i386.deb 685ddcb0ce3d778cf876a3216a7a03a3 237982 libs optional libglu1-mesa_7.0.3~rc2-1_i386.deb 790a6b512387478cb302be92f46507b4 255604 libdevel optional libglu1-mesa-dev_7.0.3~rc2-1_i386.deb f74e5cbb6ac49f7c936c9c717b2a6fd4 32414 libs optional libglw1-mesa_7.0.3~rc2-1_i386.deb b68e064f1cbab2553cff46ce30f29a83 33422 libdevel optional libglw1-mesa-dev_7.0.3~rc2-1_i386.deb 6865c50b3dcbeedaacae315194443bb2 45994 x11 optional mesa-utils_7.0.3~rc2-1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHwUZzmEvTgKxfcAwRAuWyAKCR07vtZ4yfBV3649FMzRrTDs/sKwCgwhug muY5Zn1NyZ9heO4l8SM6bso= =bYuL -END PGP SIGNATURE- Accepted: libgl1-mesa-dev_7.0.3~rc2-1_all.deb to pool/main/m/mesa/libgl1-mesa-dev_7.0.3~rc2-1_all.deb libgl1-mesa-dri-dbg_7.0.3~rc2-1_i386.deb to pool/main/m/mesa/libgl1-mesa-dri-dbg_7.0.3~rc2-1_i386.deb libgl1-mesa-dri_7.0.3~rc2-1_i386.deb to pool/main/m/mesa/libgl1-mesa-dri_7.0.3~rc2-1_i386.deb libgl1-mesa-glx-dbg_7.0.3~rc2-1_i386.deb to pool/main/m/mesa/libgl1-mesa-glx-dbg_7.0.3~rc2-1_i386.deb libgl1-mesa-glx_7.0.3~rc2-1_i386.deb to pool/main/m/mesa/libgl1-mesa-glx_7.0.3~rc2-1_i386.deb libgl1-mesa-swx11-dbg_7.0.3~rc2-1_i386.deb to pool/main/m/mesa/libgl1-mesa-swx11-dbg_7.0.3~rc2-1_i386.deb
Accepted lua-gtk 0.8+20080222-1 (source amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Sun, 24 Feb 2008 11:31:11 +0100 Source: lua-gtk Binary: liblua5.1-gtk-0 liblua5.1-gtk-dev Architecture: source amd64 Version: 0.8+20080222-1 Distribution: experimental Urgency: low Maintainer: Enrico Tassi [EMAIL PROTECTED] Changed-By: Enrico Tassi [EMAIL PROTECTED] Description: liblua5.1-gtk-0 - gtk bindings for the lua language version 5.1 liblua5.1-gtk-dev - gtk development files for the lua language version 5.1 Closes: 464140 Changes: lua-gtk (0.8+20080222-1) experimental; urgency=low . * new upstream version adding support for gtkhtml * added armel and armeb to architectures (Closes: #464140) * added build-time run testsuite based on xvfb and xmacro Files: 3531be94a035fe5f6c06f468ae0b2c95 1005 interpreters optional lua-gtk_0.8+20080222-1.dsc 5943ebfc811f3ddbb562c8e9780948ef 286158 interpreters optional lua-gtk_0.8+20080222.orig.tar.gz 662cf601fdd0515dc4fcb0e1f5caacd5 11940 interpreters optional lua-gtk_0.8+20080222-1.diff.gz 502356cd97130f0d11595c06a70db167 180130 interpreters optional liblua5.1-gtk-0_0.8+20080222-1_amd64.deb 13017b55fab4165b9245119c7d0a3828 213014 libdevel optional liblua5.1-gtk-dev_0.8+20080222-1_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHwVMh7kkcPgEj8vIRAqbdAJ4tgP615Im47lJIo0g9byLwC47BuwCeIJn+ 0CV/r83wdsyUibHxNTLBCxo= =9IR2 -END PGP SIGNATURE- Accepted: liblua5.1-gtk-0_0.8+20080222-1_amd64.deb to pool/main/l/lua-gtk/liblua5.1-gtk-0_0.8+20080222-1_amd64.deb liblua5.1-gtk-dev_0.8+20080222-1_amd64.deb to pool/main/l/lua-gtk/liblua5.1-gtk-dev_0.8+20080222-1_amd64.deb lua-gtk_0.8+20080222-1.diff.gz to pool/main/l/lua-gtk/lua-gtk_0.8+20080222-1.diff.gz lua-gtk_0.8+20080222-1.dsc to pool/main/l/lua-gtk/lua-gtk_0.8+20080222-1.dsc lua-gtk_0.8+20080222.orig.tar.gz to pool/main/l/lua-gtk/lua-gtk_0.8+20080222.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted doc-base 0.8.10 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Fri, 22 Feb 2008 23:59:05 +0100 Source: doc-base Binary: doc-base Architecture: source all Version: 0.8.10 Distribution: unstable Urgency: low Maintainer: Robert Luberda [EMAIL PROTECTED] Changed-By: Robert Luberda [EMAIL PROTECTED] Description: doc-base - utilities to manage online documentation Closes: 109431 Changes: doc-base (0.8.10) unstable; urgency=low . * doc-base.sgml: + define real section hierarchy (closes: #109431), strongly based on the menu one with a few doc-base specific sections added; + doc-base files should be UTF-8 encoded. + review TODO list. * DocBaseFile.pm: + try to recode files to UTF-8 at install time, + warn on unknown doc-base sections. * Utils.pm: Remove latin1 encoding support from HTMLEncode. * While reregistering all documents run `dhelp_parse -r' to avoid index++ runs. * Build with debhelper v6. Files: d792f9b187e60b6e4e23fa34d449cc19 540 doc optional doc-base_0.8.10.dsc 4cff5c7312a814dd13e3f8754ce4f4b8 38512 doc optional doc-base_0.8.10.tar.gz 3faca24ce0e60ffa26ed63f8d44142fd 66400 doc optional doc-base_0.8.10_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHv1jZThh1cJ0wnDsRAnkpAJ9BRdaLf6fRowerJqrJGCgJwRbObACZAWmD /VGu3NQooVT19/WYQ6uDBwM= =uZ4Z -END PGP SIGNATURE- Accepted: doc-base_0.8.10.dsc to pool/main/d/doc-base/doc-base_0.8.10.dsc doc-base_0.8.10.tar.gz to pool/main/d/doc-base/doc-base_0.8.10.tar.gz doc-base_0.8.10_all.deb to pool/main/d/doc-base/doc-base_0.8.10_all.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted ifrench 1.4-22 (source all amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Sun, 24 Feb 2008 23:49:04 +1300 Source: ifrench Binary: ifrench myspell-fr Architecture: source amd64 all Version: 1.4-22 Distribution: unstable Urgency: low Maintainer: Francois Marier [EMAIL PROTECTED] Changed-By: Francois Marier [EMAIL PROTECTED] Description: ifrench- The French dictionary for ispell (Hydro-Quebec version) myspell-fr - The French dictionary for myspell (Hydro-Quebec version) Changes: ifrench (1.4-22) unstable; urgency=low . * Compress using bzip2 * Install this dictionary for fr_CH and fr_LU as well (LP#139570) Files: 29317b190794c4aae343a53be836138d 762 text - ifrench_1.4-22.dsc 0f6318f9817cfae5b519853136b7eeb5 288135 text - ifrench_1.4-22.diff.gz 8d3fa833eaa5b7cc8533b8109967f868 714026 text extra ifrench_1.4-22_amd64.deb 6c5b8dc69d304aaa884d6bba884340c2 290538 text extra myspell-fr_1.4-22_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHwUzQScUZKBnQNIYRAtNeAKCuAXd0b6LLLMn9CXV4nJoHuyu1QQCeMz2s 2Y9tB7h/mx5Yj2NrnbO/EF0= =5QLX -END PGP SIGNATURE- Accepted: ifrench_1.4-22.diff.gz to pool/main/i/ifrench/ifrench_1.4-22.diff.gz ifrench_1.4-22.dsc to pool/main/i/ifrench/ifrench_1.4-22.dsc ifrench_1.4-22_amd64.deb to pool/main/i/ifrench/ifrench_1.4-22_amd64.deb myspell-fr_1.4-22_all.deb to pool/main/i/ifrench/myspell-fr_1.4-22_all.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted smplayer-themes 0.1.15.dfsg-1 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Thu, 07 Feb 2008 00:45:41 +0600 Source: smplayer-themes Binary: smplayer-themes Architecture: source all Version: 0.1.15.dfsg-1 Distribution: unstable Urgency: low Maintainer: [EMAIL PROTECTED] Changed-By: Matvey Kozhev [EMAIL PROTECTED] Description: smplayer-themes - complete front-end for MPlayer - icon themes Closes: 464101 464415 Changes: smplayer-themes (0.1.15.dfsg-1) unstable; urgency=low . * First upload to Debian. (Closes: #464415, #464101) * debian/control: - Update maintainer field. Files: 905db8126cc9a048fd538ba4bfc84786 652 graphics optional smplayer-themes_0.1.15.dfsg-1.dsc 8793a72b119bcc3a17d6652480602767 1539459 graphics optional smplayer-themes_0.1.15.dfsg.orig.tar.gz e8eea873b3ede2ea0423159ffd2677a1 8705 graphics optional smplayer-themes_0.1.15.dfsg-1.diff.gz 7d21d6717689d70b6e99eac7168e6680 1537660 graphics optional smplayer-themes_0.1.15.dfsg-1_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHtVLQB9xWPR9BuQcRArBZAJ4//s1wjADg+VAiYxSV+qrk1Ft1xACgij6n itDHZ0X3V5pyEgJXNLSHq5s= =aWRG -END PGP SIGNATURE- Accepted: smplayer-themes_0.1.15.dfsg-1.diff.gz to pool/main/s/smplayer-themes/smplayer-themes_0.1.15.dfsg-1.diff.gz smplayer-themes_0.1.15.dfsg-1.dsc to pool/main/s/smplayer-themes/smplayer-themes_0.1.15.dfsg-1.dsc smplayer-themes_0.1.15.dfsg-1_all.deb to pool/main/s/smplayer-themes/smplayer-themes_0.1.15.dfsg-1_all.deb smplayer-themes_0.1.15.dfsg.orig.tar.gz to pool/main/s/smplayer-themes/smplayer-themes_0.1.15.dfsg.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted freevo 1.8.0~rc1-1 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Thu, 24 Jan 2008 22:57:16 +0100 Source: freevo Binary: freevo python-freevo freevo-data freevo-lirc freevo-doc Architecture: source all Version: 1.8.0~rc1-1 Distribution: unstable Urgency: low Maintainer: Freevo Debian Dream Team [EMAIL PROTECTED] Changed-By: A Mennucc1 [EMAIL PROTECTED] Description: freevo - A Python based PVR/DVR Framework for Music and Movies freevo-data - Themes and non-application data for Freevo freevo-doc - Documentation for Freevo freevo-lirc - Lirc control for Freevo python-freevo - Python modules for Freevo Changes: freevo (1.8.0~rc1-1) unstable; urgency=low . * added /usr/share/doc/freevo/README.Debian.gz with a lot of explanations (you should read that!) * standard version to 3.7.3.0 and debian/control review * correct typos in templates, and avoid asking things twice * added many debconf questions re: data dirs, services to start... * do not run 'freevo cache' in postinst (it takes ~ 40min) * corrected most lintian warnings * added /etc/init.d scripts * fixed all permissions, so that services run as 'freevo' user * rename .deb from freevo-common to freevo-data . [Georg W. Leonhardt] * New upstream release * Add debian/freevo-common.linda-overrides and update debian/rules because ethopool.ttf are free * Bump versions off kaa-* dependencies * Add initial manpage * Add debian/watch * Cleaning freevo.dir and remove freevo-common.dir * Replace shipit vera*.tff / dejavu*.ttf with symlinks against system fonts * debian/control: Add dependencies for ttf-bitstream-vera and ttf-dejavu Files: 82deb2b80f906ae8243eef0f40b0bce9 1045 graphics optional freevo_1.8.0~rc1-1.dsc 99176067523515233115a0acda5bcc69 21199673 graphics optional freevo_1.8.0~rc1.orig.tar.gz 33d8b6bbe10870fa78ce277674930cb6 34779 graphics optional freevo_1.8.0~rc1-1.diff.gz 07e6d6c55f5bdca5e3ae9c951c4ec0d3 1568806 graphics optional freevo_1.8.0~rc1-1_all.deb 04372262afc3f4ba6a7741ec3e4c968d 690786 python optional python-freevo_1.8.0~rc1-1_all.deb 0c35f9424e89f33c5333f51645bdff25 18067042 graphics optional freevo-data_1.8.0~rc1-1_all.deb a7cd7ed8eaaeac29eca07697a4d4acda 21080 graphics optional freevo-lirc_1.8.0~rc1-1_all.deb 3848edf6c6ed03690fcec680595319cc 91026 doc optional freevo-doc_1.8.0~rc1-1_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHrgLA9B/tjjP8QKQRArZBAJ9AB3QSsn/bC2c2wWKBOlTVQTgPewCgn83J bNQK8WzdWjkFZXWdmIRembo= =7AVr -END PGP SIGNATURE- Accepted: freevo-data_1.8.0~rc1-1_all.deb to pool/main/f/freevo/freevo-data_1.8.0~rc1-1_all.deb freevo-doc_1.8.0~rc1-1_all.deb to pool/main/f/freevo/freevo-doc_1.8.0~rc1-1_all.deb freevo-lirc_1.8.0~rc1-1_all.deb to pool/main/f/freevo/freevo-lirc_1.8.0~rc1-1_all.deb freevo_1.8.0~rc1-1.diff.gz to pool/main/f/freevo/freevo_1.8.0~rc1-1.diff.gz freevo_1.8.0~rc1-1.dsc to pool/main/f/freevo/freevo_1.8.0~rc1-1.dsc freevo_1.8.0~rc1-1_all.deb to pool/main/f/freevo/freevo_1.8.0~rc1-1_all.deb freevo_1.8.0~rc1.orig.tar.gz to pool/main/f/freevo/freevo_1.8.0~rc1.orig.tar.gz python-freevo_1.8.0~rc1-1_all.deb to pool/main/f/freevo/python-freevo_1.8.0~rc1-1_all.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted ledit 2.00-2 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Sun, 24 Feb 2008 11:02:01 +0100 Source: ledit Binary: ledit Architecture: source all Version: 2.00-2 Distribution: unstable Urgency: low Maintainer: Debian OCaml Maintainers [EMAIL PROTECTED] Changed-By: Julien Cristau [EMAIL PROTECTED] Description: ledit - line editor for interactive programs Changes: ledit (2.00-2) unstable; urgency=low . * Rebuild against ocaml 3.10.1. * Add myself to Uploaders. * Remove the binary-arch rule from debian/rules; build the package in binary-indep instead (thanks, lintian!). Files: 667fed2c031e27aea4c1d99bc063b202 953 editors optional ledit_2.00-2.dsc 508e835bcdf0b47109593d5eea8d66dc 3841 editors optional ledit_2.00-2.diff.gz e3e549abbc29eab48965bda133822997 40934 editors optional ledit_2.00-2_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHwU/SmEvTgKxfcAwRArgjAJ9gzHVgH4vLB/P+mfoDSVgo1zX8agCgtR5Z aJqOgL4XJB4m4/s75cWhMxo= =HAzV -END PGP SIGNATURE- Accepted: ledit_2.00-2.diff.gz to pool/main/l/ledit/ledit_2.00-2.diff.gz ledit_2.00-2.dsc to pool/main/l/ledit/ledit_2.00-2.dsc ledit_2.00-2_all.deb to pool/main/l/ledit/ledit_2.00-2_all.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted dwww 1.10.11 (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Sun, 24 Feb 2008 11:49:32 +0100 Source: dwww Binary: dwww Architecture: source i386 Version: 1.10.11 Distribution: unstable Urgency: low Maintainer: Robert Luberda [EMAIL PROTECTED] Changed-By: Robert Luberda [EMAIL PROTECTED] Description: dwww - Read all on-line documentation with a WWW browser Changes: dwww (1.10.11) unstable; urgency=low . * dwww-convert, dwww-find, dwww-quickfind: + pass -- before arguments to external commands call, + add support for -- options' separator. * Build with debhelper v6. * debian/copyright: add copyright notice (lintian). * lib/menu*start: set charset to UTF-8. * debian/control: bump dependency on doc-base. * dwww-convert: fix setting encoding of copyright and changelogs files, which got broken in 1.10.6. Files: dd61e31cb1d4e1065fe16e5576b442f7 495 doc optional dwww_1.10.11.dsc c1065007c9d1ed92aa02b35558b647a8 115905 doc optional dwww_1.10.11.tar.gz 10520a1e89d741d1853f64549a400711 115330 doc optional dwww_1.10.11_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHwU7/Thh1cJ0wnDsRAisuAKCAgSchmrsg4mot/fKA+lFTCqnQQwCcClx4 dHJCBsFwd4o+xuqtBlUnGo4= =ukMM -END PGP SIGNATURE- Accepted: dwww_1.10.11.dsc to pool/main/d/dwww/dwww_1.10.11.dsc dwww_1.10.11.tar.gz to pool/main/d/dwww/dwww_1.10.11.tar.gz dwww_1.10.11_i386.deb to pool/main/d/dwww/dwww_1.10.11_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted ipolish 20080222-1 (source all i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Sat, 23 Feb 2008 00:25:26 +0100 Source: ipolish Binary: ipolish wpolish myspell-pl Architecture: source all i386 Version: 20080222-1 Distribution: unstable Urgency: low Maintainer: Robert Luberda [EMAIL PROTECTED] Changed-By: Robert Luberda [EMAIL PROTECTED] Description: ipolish- The Polish dictionary for ispell myspell-pl - The Polish dictionary for myspell wpolish- Polish dictionary words for /usr/share/dict Changes: ipolish (20080222-1) unstable; urgency=low . * New upstream version. * Update copyright information. * Build with debhelper v6. Files: b8a044970e865728cd1c957c4c04626b 723 text optional ipolish_20080222-1.dsc 6e967e910e0937ea882b8f8119097ebc 1076525 text optional ipolish_20080222.orig.tar.gz 766963c1cda5361c5f9416a6d3786e02 36011 text optional ipolish_20080222-1.diff.gz 8c5fb5ac8c4ee5fc71908c86255278f2 9096942 text optional wpolish_20080222-1_all.deb f28a5c8bcc160d1c7e5187299b51c5ed 1081848 text optional myspell-pl_20080222-1_all.deb e52218d6b086d8def78a2920bafd4110 2914954 text optional ipolish_20080222-1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHv9e1Thh1cJ0wnDsRAnnyAJ9NPX8wzCtdA27TqxqtI45RnpP9WQCePZC3 o6e+O/LKUTQTAlezKnofClo= =NMKg -END PGP SIGNATURE- Accepted: ipolish_20080222-1.diff.gz to pool/main/i/ipolish/ipolish_20080222-1.diff.gz ipolish_20080222-1.dsc to pool/main/i/ipolish/ipolish_20080222-1.dsc ipolish_20080222-1_i386.deb to pool/main/i/ipolish/ipolish_20080222-1_i386.deb ipolish_20080222.orig.tar.gz to pool/main/i/ipolish/ipolish_20080222.orig.tar.gz myspell-pl_20080222-1_all.deb to pool/main/i/ipolish/myspell-pl_20080222-1_all.deb wpolish_20080222-1_all.deb to pool/main/i/ipolish/wpolish_20080222-1_all.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted ejabberd 2.0.0-3 (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Sun, 24 Feb 2008 10:40:03 +0300 Source: ejabberd Binary: ejabberd Architecture: source i386 Version: 2.0.0-3 Distribution: experimental Urgency: low Maintainer: Torsten Werner [EMAIL PROTECTED] Changed-By: Sergei Golovan [EMAIL PROTECTED] Description: ejabberd - Distributed, fault-tolerant Jabber/XMPP server written in Erlang Changes: ejabberd (2.0.0-3) experimental; urgency=low . * Increased S2S timeouts. Defaults seems to be too short. * Removed a 5-minute delay between a remote server connect failure and the next connection attempt. It causes more harm than good. * Changed ownerchip of ejabberd config directory and SSL certificate to root:ejabberd and mode to to make sure they aren't overwritten by running ejabberd. * Remove an SSL certificate on package purge. It is assumed that it's a generated certificate, so the removal is unconditional. Files: b1bd3484404e043e1c07898f35c58585 890 net optional ejabberd_2.0.0-3.dsc fd9e3151873e45e5600c6c9e6e595783 29436 net optional ejabberd_2.0.0-3.diff.gz 7067465c560af7fb37b77f0fa466b5db 1122872 net optional ejabberd_2.0.0-3_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHwVFbIcdH02pGEFIRAt3eAJsGVHOG6ppkJpjrY7yMrUZoUcNTGwCeLg/b evWOI4ECoQJVX/DJPdzGQa8= =A6S6 -END PGP SIGNATURE- Accepted: ejabberd_2.0.0-3.diff.gz to pool/main/e/ejabberd/ejabberd_2.0.0-3.diff.gz ejabberd_2.0.0-3.dsc to pool/main/e/ejabberd/ejabberd_2.0.0-3.dsc ejabberd_2.0.0-3_i386.deb to pool/main/e/ejabberd/ejabberd_2.0.0-3_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted gnome-pkg-tools 0.13.3 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Sun, 24 Feb 2008 13:20:33 +0100 Source: gnome-pkg-tools Binary: gnome-pkg-tools Architecture: source all Version: 0.13.3 Distribution: unstable Urgency: low Maintainer: Debian GNOME Maintainers [EMAIL PROTECTED] Changed-By: Josselin Mouette [EMAIL PROTECTED] Description: gnome-pkg-tools - Tools for the Debian GNOME Packaging Team Changes: gnome-pkg-tools (0.13.3) unstable; urgency=low . * gnome-get-source.mk: fix the case where the zip already contains a single directory. Files: f96ee181b99e85c22b445fcc80e9675e 798 devel optional gnome-pkg-tools_0.13.3.dsc 88c4de1cdad6f118c2e1c09fc4e4887d 18367 devel optional gnome-pkg-tools_0.13.3.tar.gz b6ac9d75ac4ba96197ca0557e76efb87 22468 devel optional gnome-pkg-tools_0.13.3_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHwWKvrSla4ddfhTMRArzgAKCNka/u+PXpfTh741dXAI9Pw1mKsACeOnDi tej16ThNJC8lvhlrhMBtN/8= =AAmU -END PGP SIGNATURE- Accepted: gnome-pkg-tools_0.13.3.dsc to pool/main/g/gnome-pkg-tools/gnome-pkg-tools_0.13.3.dsc gnome-pkg-tools_0.13.3.tar.gz to pool/main/g/gnome-pkg-tools/gnome-pkg-tools_0.13.3.tar.gz gnome-pkg-tools_0.13.3_all.deb to pool/main/g/gnome-pkg-tools/gnome-pkg-tools_0.13.3_all.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted bluez-gnome 0.22-1 (source amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Thu, 14 Feb 2008 20:05:06 +0100 Source: bluez-gnome Binary: bluez-gnome Architecture: source amd64 Version: 0.22-1 Distribution: unstable Urgency: low Maintainer: Debian Bluetooth Maintainers [EMAIL PROTECTED] Changed-By: Filippo Giunchedi [EMAIL PROTECTED] Description: bluez-gnome - Bluetooth utilities for GNOME Changes: bluez-gnome (0.22-1) unstable; urgency=low . * New upstream release Files: 4236e4996195d73b2dd66e31caead627 1069 gnome optional bluez-gnome_0.22-1.dsc a2c64f942407288195934163dca19303 327905 gnome optional bluez-gnome_0.22.orig.tar.gz c7aa83398fb2fe9821ac6d2319c7c15a 3513 gnome optional bluez-gnome_0.22-1.diff.gz ad5cf0e1ab7fbd6c4366b121f719f7ed 181112 gnome optional bluez-gnome_0.22-1_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHwWBPABzeamt51AERAidFAJ9F273PG/KpanEcP5P6mwv0MC/ThgCfUq5x QCXZYdsfll83Vq/ZQb5k1jg= =WN+0 -END PGP SIGNATURE- Accepted: bluez-gnome_0.22-1.diff.gz to pool/main/b/bluez-gnome/bluez-gnome_0.22-1.diff.gz bluez-gnome_0.22-1.dsc to pool/main/b/bluez-gnome/bluez-gnome_0.22-1.dsc bluez-gnome_0.22-1_amd64.deb to pool/main/b/bluez-gnome/bluez-gnome_0.22-1_amd64.deb bluez-gnome_0.22.orig.tar.gz to pool/main/b/bluez-gnome/bluez-gnome_0.22.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted ov51x-jpeg 1.5.6-2 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Sun, 24 Feb 2008 13:48:31 +0100 Source: ov51x-jpeg Binary: ov51x-jpeg-source Architecture: source all Version: 1.5.6-2 Distribution: unstable Urgency: low Maintainer: Romain Beauxis [EMAIL PROTECTED] Changed-By: Romain Beauxis [EMAIL PROTECTED] Description: ov51x-jpeg-source - Source for the ov51x-jpeg driver Closes: 466371 Changes: ov51x-jpeg (1.5.6-2) unstable; urgency=low . * Fixed module compilation with kernel-package, thanks to Frederic Boiteux Closes: #466371 Files: 6ebe1a592ab0bec00a463e8d6ff3c523 606 graphics extra ov51x-jpeg_1.5.6-2.dsc fb4f6dccee7a3d4422c590a1d362a9ef 3930 graphics extra ov51x-jpeg_1.5.6-2.diff.gz 73ec8e64a393828b798eafd69f610f2d 81694 graphics extra ov51x-jpeg-source_1.5.6-2_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHwWklnuQ3Rt5ZmAARAjhWAJ9GmLlsgB81NI83EXDaDmO+uyPXxwCePzq4 /T2CDoNxbnJpdE6VXAcBclY= =lOcW -END PGP SIGNATURE- Accepted: ov51x-jpeg-source_1.5.6-2_all.deb to pool/main/o/ov51x-jpeg/ov51x-jpeg-source_1.5.6-2_all.deb ov51x-jpeg_1.5.6-2.diff.gz to pool/main/o/ov51x-jpeg/ov51x-jpeg_1.5.6-2.diff.gz ov51x-jpeg_1.5.6-2.dsc to pool/main/o/ov51x-jpeg/ov51x-jpeg_1.5.6-2.dsc -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted ascii 3.8-4 (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Sun, 24 Feb 2008 13:31:56 +0100 Source: ascii Binary: ascii Architecture: source i386 Version: 3.8-4 Distribution: unstable Urgency: low Maintainer: Florian Ernst [EMAIL PROTECTED] Changed-By: Florian Ernst [EMAIL PROTECTED] Description: ascii - interactive ASCII name and synonym chart Closes: 466168 Changes: ascii (3.8-4) unstable; urgency=low . * nametable fixes, many thanks to Anders Kaseorg for spotting these (partially Closes: #466168 while the full patch was forwarded upstream) * Transfer Homepage to its appropriate control field * Standards-Version 3.7.3 Files: 6f3c4d0d14e40f1ffc51251c44ae30e2 592 utils optional ascii_3.8-4.dsc 5290d19479a04cf7bd28251e2de4b15b 5001 utils optional ascii_3.8-4.diff.gz d6bffeff91935eab88eb8f221e0b5c6e 16064 utils optional ascii_3.8-4_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHwWV9s3U+TVFLPnwRAlA6AJ9npA5qAX1xGEbLreVW2o953s7c9ACfeAGx sM3zQaIV8UPlr/3X7slm8xk= =gHYW -END PGP SIGNATURE- Accepted: ascii_3.8-4.diff.gz to pool/main/a/ascii/ascii_3.8-4.diff.gz ascii_3.8-4.dsc to pool/main/a/ascii/ascii_3.8-4.dsc ascii_3.8-4_i386.deb to pool/main/a/ascii/ascii_3.8-4_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted libmail-field-received-perl 0.24-3 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Sun, 24 Feb 2008 14:00:45 + Source: libmail-field-received-perl Binary: libmail-field-received-perl Architecture: source all Version: 0.24-3 Distribution: unstable Urgency: low Maintainer: Dominic Hargreaves [EMAIL PROTECTED] Changed-By: Dominic Hargreaves [EMAIL PROTECTED] Description: libmail-field-received-perl - mostly RFC822-compliant parser of Received headers Closes: 465625 Changes: libmail-field-received-perl (0.24-3) unstable; urgency=low . * Remove test for stringify() method which is no longer supported by Mail::Field (closes: #465625) * Fix copyright notice to make lintian happy * Update Standards-Version (no changes) Files: adcf3ad8be901c48689f37cca59ff8d1 695 perl optional libmail-field-received-perl_0.24-3.dsc a9ec8cb04eed2cd343a41cb861e7157e 2486 perl optional libmail-field-received-perl_0.24-3.diff.gz 6b410fa82e375168f7e9dc1a76c6e36a 14544 perl optional libmail-field-received-perl_0.24-3_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHwXjNYzuFKFF44qURAhBqAJ9J0Z72hI/kLlCPmmJOkEQQVJ3lnwCg9c84 pYCtLupsvyWxy+UGNht5NsA= =Q1mF -END PGP SIGNATURE- Accepted: libmail-field-received-perl_0.24-3.diff.gz to pool/main/libm/libmail-field-received-perl/libmail-field-received-perl_0.24-3.diff.gz libmail-field-received-perl_0.24-3.dsc to pool/main/libm/libmail-field-received-perl/libmail-field-received-perl_0.24-3.dsc libmail-field-received-perl_0.24-3_all.deb to pool/main/libm/libmail-field-received-perl/libmail-field-received-perl_0.24-3_all.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted cl-rsm-rsa 1.3+cvs.2004.03.30 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Sun, 24 Feb 2008 15:45:21 +0100 Source: cl-rsm-rsa Binary: cl-rsm-rsa Architecture: source all Version: 1.3+cvs.2004.03.30 Distribution: unstable Urgency: low Maintainer: Debian Common Lisp Team [EMAIL PROTECTED] Changed-By: Peter Van Eynde [EMAIL PROTECTED] Description: cl-rsm-rsa - McIntire's Common Lisp RSA Library Changes: cl-rsm-rsa (1.3+cvs.2004.03.30) unstable; urgency=low . * Changed to group maintanance * Added Vcs-Git control field * swap binary-indep and binary-arch * Updated standard version without real changes * debhelper is Build-Depends Files: 706817818ae10773956c288e43856ade 678 devel optional cl-rsm-rsa_1.3+cvs.2004.03.30.dsc e5dad392c36131eafc9c084d9652767f 11084 devel optional cl-rsm-rsa_1.3+cvs.2004.03.30.tar.gz ea36e6d314aceeac23f44f973736b7ec 11106 devel optional cl-rsm-rsa_1.3+cvs.2004.03.30_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHwYML11ldN0tyliURAqeqAKCXL2BQuFBJVhxWrZIyPgsmHM6DDwCeKtfn 0EttKaym+AaRh7ShV6Q9rzI= =KTnm -END PGP SIGNATURE- Accepted: cl-rsm-rsa_1.3+cvs.2004.03.30.dsc to pool/main/c/cl-rsm-rsa/cl-rsm-rsa_1.3+cvs.2004.03.30.dsc cl-rsm-rsa_1.3+cvs.2004.03.30.tar.gz to pool/main/c/cl-rsm-rsa/cl-rsm-rsa_1.3+cvs.2004.03.30.tar.gz cl-rsm-rsa_1.3+cvs.2004.03.30_all.deb to pool/main/c/cl-rsm-rsa/cl-rsm-rsa_1.3+cvs.2004.03.30_all.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted cl-ptester 2.1.2-5 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Sun, 24 Feb 2008 12:49:47 +0100 Source: cl-ptester Binary: cl-ptester Architecture: source all Version: 2.1.2-5 Distribution: unstable Urgency: low Maintainer: Debian Common Lisp Team [EMAIL PROTECTED] Changed-By: Peter Van Eynde [EMAIL PROTECTED] Description: cl-ptester - Test suite for Common Lisp programs Changes: cl-ptester (2.1.2-5) unstable; urgency=low . * Changed to group maintanance * Added Vcs-Git control field * Updated standard version without real changes * swap binary-indep and binary-arch * Added homepage field Files: 72a199b53a7b472b5504141b619f3b76 787 devel optional cl-ptester_2.1.2-5.dsc e110b38333c7c1045c78fee78b39b4a9 4402 devel optional cl-ptester_2.1.2-5.diff.gz 633626ad89b279e4c6e731832d142bf5 13452 devel optional cl-ptester_2.1.2-5_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHwVnn11ldN0tyliURAhzVAJ9iRiu5Jmqj/EN0WnAxVaCdyyOXwwCbBxtd SB0x8hskdN9kY92y7DG0NG0= =KyGj -END PGP SIGNATURE- Accepted: cl-ptester_2.1.2-5.diff.gz to pool/main/c/cl-ptester/cl-ptester_2.1.2-5.diff.gz cl-ptester_2.1.2-5.dsc to pool/main/c/cl-ptester/cl-ptester_2.1.2-5.dsc cl-ptester_2.1.2-5_all.deb to pool/main/c/cl-ptester/cl-ptester_2.1.2-5_all.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted cl-rsm-bool-comp 1.2 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Sun, 24 Feb 2008 15:06:14 +0100 Source: cl-rsm-bool-comp Binary: cl-rsm-bool-comp Architecture: source all Version: 1.2 Distribution: unstable Urgency: low Maintainer: Debian Common Lisp Team [EMAIL PROTECTED] Changed-By: Peter Van Eynde [EMAIL PROTECTED] Description: cl-rsm-bool-comp - Common Lisp Boolean Function Comparison Library Changes: cl-rsm-bool-comp (1.2) unstable; urgency=low . * Changed to group maintanance * Added Vcs-Git control field * Updated standard version without real changes * debhelper is Build-Depends * swap binary-indep and binary-arch Files: 53dd9cedb3cdfeb9130ec3cda5365f6e 672 devel optional cl-rsm-bool-comp_1.2.dsc c897e57dcae427d8636cb68d4bf555b5 43596 devel optional cl-rsm-bool-comp_1.2.tar.gz bec65c86d433518267958bdd0de3bc63 43042 devel optional cl-rsm-bool-comp_1.2_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHwXnk11ldN0tyliURAmFpAKCPKV/fxX15p+NloXNaygYZzulLgwCfdjAj Xd+CLPhOt7McTRxY9ZHnHys= =eOn+ -END PGP SIGNATURE- Accepted: cl-rsm-bool-comp_1.2.dsc to pool/main/c/cl-rsm-bool-comp/cl-rsm-bool-comp_1.2.dsc cl-rsm-bool-comp_1.2.tar.gz to pool/main/c/cl-rsm-bool-comp/cl-rsm-bool-comp_1.2.tar.gz cl-rsm-bool-comp_1.2_all.deb to pool/main/c/cl-rsm-bool-comp/cl-rsm-bool-comp_1.2_all.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted cl-quick-arrays 20080224 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Sun, 24 Feb 2008 14:57:12 +0100 Source: cl-quick-arrays Binary: cl-quick-arrays Architecture: source all Version: 20080224 Distribution: unstable Urgency: low Maintainer: Debian Common Lisp Team [EMAIL PROTECTED] Changed-By: Peter Van Eynde [EMAIL PROTECTED] Description: cl-quick-arrays - A library offering less flexible, but faster arrays Changes: cl-quick-arrays (20080224) unstable; urgency=low . * Changed to group maintanance * Added Vcs-Git control field * Now uses debian/compat * debhelper is Build-Depends * Updated standard version without real changes * swap binary-indep and binary-arch Files: c98925a028750361977005ece0d17849 678 libs optional cl-quick-arrays_20080224.dsc 74539ffcfa1f241e36a76c895fbda347 12012 libs optional cl-quick-arrays_20080224.tar.gz f4ac8052fab218b9b2571df859ad9d47 13540 libs optional cl-quick-arrays_20080224_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHwXgp11ldN0tyliURAvdwAJ9n2r2qNxwsAr6m7KHSgqN4y3/j6QCfSo2/ SHYsAehJVQoE8got9SZIj3g= =IZdm -END PGP SIGNATURE- Accepted: cl-quick-arrays_20080224.dsc to pool/main/c/cl-quick-arrays/cl-quick-arrays_20080224.dsc cl-quick-arrays_20080224.tar.gz to pool/main/c/cl-quick-arrays/cl-quick-arrays_20080224.tar.gz cl-quick-arrays_20080224_all.deb to pool/main/c/cl-quick-arrays/cl-quick-arrays_20080224_all.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted cl-rsm-finance 1.3 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Sun, 24 Feb 2008 15:16:43 +0100 Source: cl-rsm-finance Binary: cl-rsm-finance Architecture: source all Version: 1.3 Distribution: unstable Urgency: low Maintainer: Debian Common Lisp Team [EMAIL PROTECTED] Changed-By: Peter Van Eynde [EMAIL PROTECTED] Description: cl-rsm-finance - McIntire's Common Lisp Finance Library Changes: cl-rsm-finance (1.3) unstable; urgency=low . * Changed to group maintanance * Added Vcs-Git control field * Updated standard version without real changes * debhelper is Build-Depends * swap binary-indep and binary-arch Files: 491a48c99c45c4128995e13daaa66712 664 devel optional cl-rsm-finance_1.3.dsc 2408ca2636f6b980b09c2d7e760c0591 13348 devel optional cl-rsm-finance_1.3.tar.gz 3071fe9348b0d9d7619b8866ca3d92ba 12598 devel optional cl-rsm-finance_1.3_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHwXxU11ldN0tyliURAlpIAJ0YDQvIQDUSicQ7gTqmglHaPm/CqwCeLEx+ SX+kLx4qN0K8reY8uEnxnTA= =tsoB -END PGP SIGNATURE- Accepted: cl-rsm-finance_1.3.dsc to pool/main/c/cl-rsm-finance/cl-rsm-finance_1.3.dsc cl-rsm-finance_1.3.tar.gz to pool/main/c/cl-rsm-finance/cl-rsm-finance_1.3.tar.gz cl-rsm-finance_1.3_all.deb to pool/main/c/cl-rsm-finance/cl-rsm-finance_1.3_all.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted cl-rsm-fuzzy 1.4 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Sun, 24 Feb 2008 15:17:55 +0100 Source: cl-rsm-fuzzy Binary: cl-rsm-fuzzy Architecture: source all Version: 1.4 Distribution: unstable Urgency: low Maintainer: Debian Common Lisp Team [EMAIL PROTECTED] Changed-By: Peter Van Eynde [EMAIL PROTECTED] Description: cl-rsm-fuzzy - McIntire's Common Lisp Fuzzy Logic Library Changes: cl-rsm-fuzzy (1.4) unstable; urgency=low . * Changed to group maintanance * Added Vcs-Git control field * Updated standard version without real changes * debhelper is Build-Depends * swap binary-indep and binary-arch Files: 32eec5761ee7c248d7c45ff566b8a605 656 devel optional cl-rsm-fuzzy_1.4.dsc 5ace53910cd9ba2a02a25f3610754524 14644 devel optional cl-rsm-fuzzy_1.4.tar.gz 643430853572bd3fd2a123f720bab917 14676 devel optional cl-rsm-fuzzy_1.4_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHwXyu11ldN0tyliURAobXAJ9F0YtZK12kBu0i/rIRY5eG971MygCcCSDP sUCqUsrtNpSysKbyC6GFSjo= =B/cE -END PGP SIGNATURE- Accepted: cl-rsm-fuzzy_1.4.dsc to pool/main/c/cl-rsm-fuzzy/cl-rsm-fuzzy_1.4.dsc cl-rsm-fuzzy_1.4.tar.gz to pool/main/c/cl-rsm-fuzzy/cl-rsm-fuzzy_1.4.tar.gz cl-rsm-fuzzy_1.4_all.deb to pool/main/c/cl-rsm-fuzzy/cl-rsm-fuzzy_1.4_all.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted cl-screamer 3.24.2-3 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Sun, 24 Feb 2008 12:44:58 +0100 Source: cl-screamer Binary: cl-screamer Architecture: source all Version: 3.24.2-3 Distribution: unstable Urgency: low Maintainer: Debian Common Lisp Team [EMAIL PROTECTED] Changed-By: Peter Van Eynde [EMAIL PROTECTED] Description: cl-screamer - Common Lisp package for non-determinate programming Changes: cl-screamer (3.24.2-3) unstable; urgency=low . * Changed to group maintanance * Added Vcs-Git control field * Added homepage field * Updated standard version without real changes * swap binary-indep and binary-arch * debhelper is Build-Depends Files: 3726b859c2e3c3480f5a42ea28bd389b 795 devel optional cl-screamer_3.24.2-3.dsc 7a7caea199bdb3709f199f8d04decee8 4175 devel optional cl-screamer_3.24.2-3.diff.gz 7711a86a1d160b38db65fac80ee6a8bb 197816 devel optional cl-screamer_3.24.2-3_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHwVjN11ldN0tyliURAuuaAKDKOtUxViBIGIkZaT++vKe7df2QNACgnyFn 6siZm0f1XxLyqQUFOVHV7LQ= =yFeI -END PGP SIGNATURE- Accepted: cl-screamer_3.24.2-3.diff.gz to pool/main/c/cl-screamer/cl-screamer_3.24.2-3.diff.gz cl-screamer_3.24.2-3.dsc to pool/main/c/cl-screamer/cl-screamer_3.24.2-3.dsc cl-screamer_3.24.2-3_all.deb to pool/main/c/cl-screamer/cl-screamer_3.24.2-3_all.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
