Re: postinst scripts failing because a new conffile wasn't accepted: Is it a bug?
On 11/1/05, Frank Lichtenheld [EMAIL PROTECTED] wrote: On Mon, Oct 31, 2005 at 06:56:44PM +0100, Frank Küster wrote: In my opinion this is not a bug (except if the package is crucial for the system to work and be reachable, like ssh) - the local admin simply has to review the changes to conffiles that dpkg requested, and have a look at NEWS.Debian and changelog.Debian. If these files do not contain enough information to fix the system, then this is a bug, right? But the simple fact that a postinst script fails because a change has been refused isn't - and for sure it is not a serious or grave bug, severities often used when a postinst fails. Opinions? There is one big problem with that scenario that I haven't seen mentioned in this thread yet: If I make the dist-upgrade of a machine from sarge to etch and the dist-upgrade fails right in the middle of the installed 3000 packages I will be severly disappointed to say the least if that didn't happen for a very good reason... That's a fact that often gets lost when discussing such problem from developer to developer that install sid on their machines and update about 30 packages at once. So if it is at all possible to avoid failing the postinst (which of course also means to not break other packages installation as you have pointed out) it should be done. Wouldn't it be better to improve apt so it doesn't abort if a single package fails? It should still be able to continue with independent packages.
Re: Help: Bug#336469: pure-ftpd uninstallable : no pure-ftpd-common
Scripsit Steve Langasek [EMAIL PROTECTED]
No, it's a bug in dpkg-dev, which should know how to set ${Source-Version}
correctly for binNMUs.
It can't really know, can it? If I have a control file with
Package: foo
Architecture: any
Package: foo-data-extra
Architecture: all
Package: foo-plugins
Architecture: any
Depends: foo (=${Source-Version}), foo-data-extra (=${Source-Version})
then a binNMU ought to have foo-plugins depend on the binNMU'ed
version of foo, but on the common version of foo-data-extra.
If dpkg-gencontrol were to figure out that, it would need to parse a
lot of data that it currently doesn't. And even if it did it
correctly, the resulting behavior would be confusing.
IMO it would be better to split ${Source-Version} into two substvars,
one of which includes binNMU suffixes and one of which doesn't.
--
Henning Makholm In my opinion, this child don't
need to have his head shrunk at all.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Transition time: KDE, JACK, arts, sablotron, unixodbc, net-snmp, php, ...
Scripsit Josh Metzler [EMAIL PROTECTED] On Monday 31 October 2005 09:54 am, Henning Makholm wrote: This confuses me a bit; I thought that 'autotrace' was in the mess too (due to libmagick and libpstoedit transitions), and had an upload to make it installable-in-sid planned for tonight, now that pstoedit has been fixed again. However, autotrace appears on neither of your lists. http://packages.qa.debian.org/autotrace indicates that autotrace is not in testing right now, so supposedly it was already removed. Interesting. I don't think anybody will miss autotrace in testing for the time being (it exists mostly because it's a build-dependency of something), but it would be nice if the maintainter was informed when a package gets removed from testing. -- Henning Makholm Man vælger jo selv sine forbilleder.
Re: Best practices on system users and groups
ma, 2005-10-31 kello 22:03 +0100, Javier Fernández-Sanguino Peña kirjoitti: After the feedback of the recent d-d thread, I've adapted the section I wrote on the best practices related to system users and groups, it is currently available at: http://www.debian.org/doc/manuals/developers-reference/ch-best-pkging-practices.en.html#s-bpp-lower-privs I would like developers to review and provide feedback for that section, specially in form of patches. I'm considering doing a bug hunt for: DON'T do this: addgroup --quiet --system $SERVER_GROUP 2/dev/null ||true When (not if!) addgroup fails, the poor system administrator gets no indication of it. This is a bug, and a pretty bad one. If adduser isn't quiet enough with --quiet, then fix that, don't hide real errors. Remove both the redirect and the || true. Also, sticking all the tens of lines of boilerplate code into the postinst of every package that needs a system user is a good way to invite trouble. When the boilerplate has a bug (possibly because things change in the future), it will have to be fixed in dozes on of packages. It's oh so much more sensible to create a tool that postinsts can call: if boilerplate code is good enough, then it can easily be abstracted away. -- Fundamental truth #1: Complexity is the enemy.
Re: postinst scripts failing because a new conffile wasn't accepted: Is it a bug?
Frank Lichtenheld [EMAIL PROTECTED] wrote: On Mon, Oct 31, 2005 at 06:56:44PM +0100, Frank Küster wrote: In my opinion this is not a bug (except if the package is crucial for the system to work and be reachable, like ssh) - the local admin simply has to review the changes to conffiles that dpkg requested, and have a look at NEWS.Debian and changelog.Debian. If these files do not contain enough information to fix the system, then this is a bug, right? But the simple fact that a postinst script fails because a change has been refused isn't - and for sure it is not a serious or grave bug, severities often used when a postinst fails. Opinions? There is one big problem with that scenario that I haven't seen mentioned in this thread yet: If I make the dist-upgrade of a machine from sarge to etch and the dist-upgrade fails right in the middle of the installed 3000 packages I will be severly disappointed to say the least if that didn't happen for a very good reason... That's a fact that often gets lost when discussing such problem from developer to developer that install sid on their machines and update about 30 packages at once. Maybe we need a policy (or a change in dpkg's default behavior) for that. One option would be to recommend to take the new version and merge local changes afterwards (but this might severely break more important things, like ssh in an environment where port 22 is blocked...). Or on the other hand, packages that change incompatibly must ensure that they are not installed automatically - however that would mean that every package that build-depends on the changed package would have to change its control file. So if it is at all possible to avoid failing the postinst (which of course also means to not break other packages installation as you have pointed out) it should be done. If it is at all possible in the case of tetex I can't tell, though. I do not see how it could be made possible. Oh, yes, there is one way, and we have even tried to go that route: After the conffile questions have been asked, we check in the postinst script whether some essential entries in ucf-managed configuration files are wrong, and if they are we change the file. But we can't do that for dpkg-managed files, and in any case I don't want to have a 1000 line postinst script because it checks for 30 possibly fatal refused changes... Regards, Frank -- Frank Küster Inst. f. Biochemie der Univ. Zürich Debian Developer
Re: postinst scripts failing because a new conffile wasn't accepted: Is it a bug?
Scripsit Frank Küster [EMAIL PROTECTED] These variables can be changed by a configuration file, and some of them *must* be set. Now if a user refuses to accept the change that switches from VARTEXMF to TEXMFVAR (or TEXMFSYSVAR, actually), TeX can no longer work. You seem to assume that the *only* way to get this change into the file is to forcibly discard all of the sysadmin's local adaptations and install a pristine upstream version of the conffile. Why do you want to deny the sysadmin the opportunity to do the changes himself? He presumably did have a good reason to make the local adaptations he did, and who are you do decree that his preferred method of solution MUST be to redo all of his local adaptations by hand, instead of to make the simple upstream change to one line in the file by hand? -- Henning Makholm It will be useful even at this early stage to review briefly the main features of the universe as they are known today.
Re: Transition time: KDE, JACK, arts, sablotron, unixodbc, net-snmp, php, ...
On Tue, Nov 01, 2005 at 09:29:58AM +0100, Henning Makholm wrote: Scripsit Josh Metzler [EMAIL PROTECTED] On Monday 31 October 2005 09:54 am, Henning Makholm wrote: This confuses me a bit; I thought that 'autotrace' was in the mess too (due to libmagick and libpstoedit transitions), and had an upload to make it installable-in-sid planned for tonight, now that pstoedit has been fixed again. However, autotrace appears on neither of your lists. http://packages.qa.debian.org/autotrace indicates that autotrace is not in testing right now, so supposedly it was already removed. Interesting. I don't think anybody will miss autotrace in testing for the time being (it exists mostly because it's a build-dependency of something), but it would be nice if the maintainter was informed when a package gets removed from testing. This is a reasonable concern, but the standing policy is that if a package is RC-buggy, it's a candidate for removal from testing at any time. We would like to get notices to maintainers set up, but in the majority of cases the presence of an RC bug on the package is already ample notice. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: Transition time: KDE, JACK, arts, sablotron, unixodbc, net-snmp, php, ...
Henning Makholm [EMAIL PROTECTED] wrote: Scripsit Josh Metzler [EMAIL PROTECTED] On Monday 31 October 2005 09:54 am, Henning Makholm wrote: This confuses me a bit; I thought that 'autotrace' was in the mess too (due to libmagick and libpstoedit transitions), and had an upload to make it installable-in-sid planned for tonight, now that pstoedit has been fixed again. However, autotrace appears on neither of your lists. http://packages.qa.debian.org/autotrace indicates that autotrace is not in testing right now, so supposedly it was already removed. Interesting. I don't think anybody will miss autotrace in testing for the time being (it exists mostly because it's a build-dependency of something), but it would be nice if the maintainter was informed when a package gets removed from testing. ... and if the maintainer had some place where they could look up the rationale. Regards, Frank -- Frank Küster Inst. f. Biochemie der Univ. Zürich Debian Developer
Re: Help: Bug#336469: pure-ftpd uninstallable : no pure-ftpd-common
On Tue, Nov 01, 2005 at 09:27:06AM +0100, Henning Makholm wrote:
Scripsit Steve Langasek [EMAIL PROTECTED]
No, it's a bug in dpkg-dev, which should know how to set ${Source-Version}
correctly for binNMUs.
It can't really know, can it? If I have a control file with
Package: foo
Architecture: any
Package: foo-data-extra
Architecture: all
Package: foo-plugins
Architecture: any
Depends: foo (=${Source-Version}), foo-data-extra (=${Source-Version})
then a binNMU ought to have foo-plugins depend on the binNMU'ed
version of foo, but on the common version of foo-data-extra.
If dpkg-gencontrol were to figure out that, it would need to parse a
lot of data that it currently doesn't. And even if it did it
correctly, the resulting behavior would be confusing.
IMO it would be better to split ${Source-Version} into two substvars,
one of which includes binNMU suffixes and one of which doesn't.
Yes; sorry, I thought it was self-evident that Source-Version ought to refer
to the *source* version, and that a new variable name is called for where
the binary version is needed.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
[EMAIL PROTECTED] http://www.debian.org/
signature.asc
Description: Digital signature
Re: Best practices on system users and groups
hi javier, On Mon, Oct 31, 2005 at 10:03:01PM +0100, Javier Fernández-Sanguino Peña wrote: I would like developers to review and provide feedback for that section, thanks for actually putting this into a document, however, i notice two problems: - the addgroup/adduser functions mask the error status, yet do not later check to see if the group was actually created. this is doubly bad, because not only will the package continue to install, but no error message or warning is even printed. here's a patch for adding a group: --- foo 2005-11-01 10:29:15.0 +0100 +++ bar 2005-11-01 10:32:27.0 +0100 @@ -28,8 +28,13 @@ # 1. create group if not existing if ! getent group | grep -q ^$SERVER_GROUP: ; then echo -n Adding group $SERVER_GROUP.. - addgroup --quiet --system $SERVER_GROUP 2/dev/null ||true - echo ..done + addgroup --quiet --system $SERVER_GROUP ||true + if ! getent group | grep -q ^$SERVER_GROUP:; then + echo ...error encountered + exit 1 + else + echo ...done + fi fi ... and the same for adding users. the second thing i notice is that you arbitrarily modify the user in question via usermod, which would override the local admin's changes. i wonder whether it is even good to recommend this at all. On Tue, Nov 01, 2005 at 11:14:59AM +0200, Lars Wirzenius wrote: Also, sticking all the tens of lines of boilerplate code into the postinst of every package that needs a system user is a good way to invite trouble. When the boilerplate has a bug (possibly because things change in the future), it will have to be fixed in dozes on of packages. It's oh so much more sensible to create a tool that postinsts can call: if boilerplate code is good enough, then it can easily be abstracted away. i'd like to double-ack this remark. even if the oft-mentioned dh_user were implemented, if there were a bug in this implementation, every affected package would have to be /rebuilt/ if the buggy code were actually in the postinsts. if you're going to do this, it would be better to provide a program or a shell library that is sourced in the postinst, and then awrapper function which does all of this. sean -- signature.asc Description: Digital signature
Re: Packages file missing from unstable archive
On Sun, Oct 30, 2005 at 09:48:35AM +0100, Goswin von Brederlow wrote: Zsync checksum files are, depending on block size, about 3% of the file size. For the full archive that means under 10G more data. As comparison adding amd64 needs ~30G. After the scc split there might be enough space on mirrors for both. Adding amd64 needs 30G? Since when? And stuff doesn't go on the mirrors because it's under 30G, it goes on the mirrors because it provides useful benefits. Where're the statistics showing how much zsync signatures actually help? Cheers, aj signature.asc Description: Digital signature
Re: Best practices on system users and groups
ma, 2005-10-31 kello 22:03 +0100, Javier Fernández-Sanguino Peña kirjoitti: I would like developers to review and provide feedback for that section, specially in form of patches. I'm considering doing a bug hunt for: Typically this means that the configuration files are owned by group, belong to the group of the system user and are mode 0640. Owned by group? What group? If the daemon logs to a directory under /var/log/ then *it* should be owned by the system user and rotated log files need not be changed ownership. What does *it* mean? The directory or the log file?
Re: Transition time: KDE, JACK, arts, sablotron, unixodbc, net-snmp, php, ...
Scripsit Steve Langasek [EMAIL PROTECTED] On Tue, Nov 01, 2005 at 09:29:58AM +0100, Henning Makholm wrote: Interesting. I don't think anybody will miss autotrace in testing for the time being (it exists mostly because it's a build-dependency of something), but it would be nice if the maintainter was informed when a package gets removed from testing. This is a reasonable concern, but the standing policy is that if a package is RC-buggy, it's a candidate for removal from testing at any time. The fact that it is a candidate for removal is a completely different state from it _has_ been removed. I don't see how you can suppose that the difference is not important for maintainers. Also, the only RC bugginess that has applied to autotrace in recent memory is that it was uninstallable in sid due to library transitions, and not uploadable because its build-dependencies were not in order yet (which was duly noted in the bug reports). I do not think this falls under a maintainer himself ignores his bugs and therefore deserves to be left in the dark heading. Well, the build-dependencies became fixed about 4 days ago (courtesy of a NMU by yours truly). Is 4 days enough to get something removed from testing? We would like to get notices to maintainers set up, but in the majority of cases the presence of an RC bug on the package is already ample notice. No it's not. RC bug, still in testing - fixing this is very important, because it may hold up the testing migration of other packages. RC bug, not in testing - fixing this only affects this one package, and is therefore not so urgent. The removal from testing drastically changes which priorities I should use in allocating the time I can use for Debian stuff. -- Henning Makholm I've been staying out of family conversations. Do I get credit for that? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: postinst scripts failing because a new conffile wasn't accepted: Is it a bug?
Henning Makholm [EMAIL PROTECTED] wrote: Scripsit Frank Küster [EMAIL PROTECTED] These variables can be changed by a configuration file, and some of them *must* be set. Now if a user refuses to accept the change that switches from VARTEXMF to TEXMFVAR (or TEXMFSYSVAR, actually), TeX can no longer work. You seem to assume that the *only* way to get this change into the file is to forcibly discard all of the sysadmin's local adaptations and install a pristine upstream version of the conffile. No, of course there is an other way: dpkg offers an option to start a shell (or put itself in the background or whatever) to clear up the situation; or one can simply log in on a different terminal. But if the local admin doesn't want to do that, but delay merging the configuration file, there are only two possibilities: Either he accepts the new maintainer's version, or he refuses it. And the latter choice leads to a failure of the postinst script in some cases. It's only *some* cases; I think in the most important cases, the file isn't dpkg-managed (but ucf-managed), anyway, so we choose to forcibly introduce the variable name changes if the rest of the line was unchanged (or recognizable). But that cannot always be done, and in fact the reason why I decided to ask this is because a user had an old version of a conffile of an other package. The other package depends on tetex, and must recreate its format (reinitialize) when tetex is updated - and made tetex's postinst fail. Why do you want to deny the sysadmin the opportunity to do the changes himself? I don't. All I do is request some support for the view that if he decides to do so, he should in fact do it before filing a bug; and if he files a bug that I can close or downgrade it to non-RC severity. Regards, Frank -- Frank Küster Inst. f. Biochemie der Univ. Zürich Debian Developer
Re: Best practices on system users and groups
On 31/10/2005 Javier Fernández-Sanguino Peña wrote: After the feedback of the recent d-d thread, I've adapted the section I wrote on the best practices related to system users and groups, it is currently available at: http://www.debian.org/doc/manuals/developers-reference/ch-best-pkging-practices.en.html#s-bpp-lower-privs the group deletion has currently a problem. From 6.5.1.3 'Removing system users': # Remove system group if is a system group CREATEDGROUP=server_group if [ -r /etc/adduser.conf ] ; then FIRST_USER_GID=`grep ^USERS_GID /etc/adduser.conf | cut -f2 -d '='` else FIRST_USER_GID=1000 fi if [ -n $FIST_USER_GID ] then if GROUPGID=`getent group $CREATEDGROUP | cut -f 3 -d ':'`; then if [ -n $GROUPGID ]; then if [ $FIST_USER_GID -gt $GROUPGID ]; then echo -n Removing $CREATEDGROUP group.. delgroup --only-if-empty $CREATEDGROUP || true echo ..done fi fi fi fi first, the 'if [ -n $FIST_USER_GID ] then' should better be 'if [ -n $FIRST_USER_GID]; then' (two small typos). second, and more important, the default GID for the group 'users' is 100 for adduser, so the check above will always fail. system groups created via 'addgroup --system' have GIDs between 100 and 199. in my eyes it would be more sane to check for FIRST_SYSTEM_GID instead of USERS_GID. ... jonas signature.asc Description: Digital signature
Re: Best practices on system users and groups
On 01/11/2005 To Debian-Devel wrote: the group deletion has currently a problem. From 6.5.1.3 'Removing system users': # Remove system group if is a system group CREATEDGROUP=server_group if [ -r /etc/adduser.conf ] ; then FIRST_USER_GID=`grep ^USERS_GID /etc/adduser.conf | cut -f2 -d '='` else FIRST_USER_GID=1000 fi if [ -n $FIST_USER_GID ] then if GROUPGID=`getent group $CREATEDGROUP | cut -f 3 -d ':'`; then if [ -n $GROUPGID ]; then if [ $FIST_USER_GID -gt $GROUPGID ]; then echo -n Removing $CREATEDGROUP group.. delgroup --only-if-empty $CREATEDGROUP || true echo ..done fi fi fi fi second, and more important, the default GID for the group 'users' is 100 for adduser, so the check above will always fail. system groups created via 'addgroup --system' have GIDs between 100 and 199. in my eyes it would be more sane to check for FIRST_SYSTEM_GID instead of USERS_GID. sorry, i mean LAST_SYSTEM_GID. best would be: FIRST_SYSTEM_GID=`grep ^FIRST_SYSTEM_GID /etc/adduser.conf | cut -f2 -d '='` LAST_SYSTEM_GID=`grep ^LAST_SYSTEM_GID /etc/adduser.conf | cut -f2 -d '='` [...] if [ $LAST_SYSTEM_GID -gt $GROUPGID ] [ $FIRST_SYSTEM_GID -lt $GROUPGID ]; then [...] fi ... jonas signature.asc Description: Digital signature
Re: Transition time: KDE, JACK, arts, sablotron, unixodbc, net-snmp, php, ...
Scripsit Henning Makholm [EMAIL PROTECTED] Scripsit Steve Langasek [EMAIL PROTECTED] This is a reasonable concern, but the standing policy is that if a package is RC-buggy, it's a candidate for removal from testing at any time. The fact that it is a candidate for removal is a completely different state from it _has_ been removed. I don't see how you can suppose that the difference is not important for maintainers. Calm down, Henning ... view this as an opportunity to contribute rather than a reason to complain. So, would anybody object if I set up a cronjob that emails the PTS whenever a (source) package propagates to, or is removed from, testing? -- Henning Makholm I always thought being *real* sad would be *cooler* than acting *fake* sad, but it's not. It's not cool at *all*. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: postinst scripts failing because a new conffile wasn't accepted: Is it a bug?
Scripsit Frank Küster [EMAIL PROTECTED] Henning Makholm [EMAIL PROTECTED] wrote: You seem to assume that the *only* way to get this change into the file is to forcibly discard all of the sysadmin's local adaptations and install a pristine upstream version of the conffile. No, of course there is an other way: dpkg offers an option to start a shell (or put itself in the background or whatever) to clear up the situation; or one can simply log in on a different terminal. Exactly, but what happens then is 1. User backgrounds dpkg, or switches to another window. 2. User edits the file to take into account the new variable name. 3. User returns to dpkg. 4. User selects the No, I'm happy with my own version as it look now menu option. Your proposal, if I understand you correctly, is to make (4) result in the postinst failing even though the user _has_ taken care of the problem. But if the local admin doesn't want to do that, but delay merging the configuration file, there are only two possibilities: Either he accepts the new maintainer's version, or he refuses it. And the latter choice leads to a failure of the postinst script in some cases. This is not true. If he edits the file himself (but refuses the maintainer's version because accepting it would lead to his own changes being overwritten) things still work fine. Why do you want to deny the sysadmin the opportunity to do the changes himself? I don't. You want the postinst to fail if he does the changes himself rather than abandoning all of his local changes, right? That is _not_ how conffiles are supposed to work. All I do is request some support for the view that if he decides to do so, he should in fact do it before filing a bug; Of course it is not a bug if the package fails because the admin does not properly adjust his conffiles. But it _is_ a bug if the postinst refuses to do its work unless it gets to overwrite the conffile with a pristine upstream version. -- Henning Makholm Wir kommen nun ans Ziel unserer Ausführungen.
Re: postinst scripts failing because a new conffile wasn't accepted: Is it a bug?
Henning Makholm [EMAIL PROTECTED] wrote: Scripsit Frank Küster [EMAIL PROTECTED] Henning Makholm [EMAIL PROTECTED] wrote: You seem to assume that the *only* way to get this change into the file is to forcibly discard all of the sysadmin's local adaptations and install a pristine upstream version of the conffile. No, of course there is an other way: dpkg offers an option to start a shell (or put itself in the background or whatever) to clear up the situation; or one can simply log in on a different terminal. Exactly, but what happens then is 1. User backgrounds dpkg, or switches to another window. 2. User edits the file to take into account the new variable name. 3. User returns to dpkg. 4. User selects the No, I'm happy with my own version as it look now menu option. Your proposal, if I understand you correctly, is to make (4) result in the postinst failing even though the user _has_ taken care of the problem. You must have misunderstood me. I don't check whether the installed file is the one I expect; I simply run fmtutil --all - and that will fail if he hasn't solved the problem. But if the local admin doesn't want to do that, but delay merging the configuration file, there are only two possibilities: Either he accepts the new maintainer's version, or he refuses it. And the latter choice leads to a failure of the postinst script in some cases. This is not true. It is - with that I meant to edit the file now. If he edits the file himself (but refuses the maintainer's version because accepting it would lead to his own changes being overwritten) things still work fine. Of course they will. In particular, I won't get a bug report and won't have to consider closing or downgrading it, and ask questions on -devel :-) Why do you want to deny the sysadmin the opportunity to do the changes himself? I don't. You want the postinst to fail if he does the changes himself rather than abandoning all of his local changes, right? No, if I have written something like this I must have been insane. All I want to say is: If he does the changes himself bug does it wrong, the fmtutil call (or updmap or whatever) in postinst will fail. But this is in fact a corner case, the usual situation is that the user pressed keep local version without thinking, or simply uses the noninteractive frontend and doesn't bother himself with looking at any *.dpkg-new files before reporting the bug. All I do is request some support for the view that if he decides to do so, he should in fact do it before filing a bug; Of course it is not a bug if the package fails because the admin does not properly adjust his conffiles. So finally there is one person who simply says yes to the question in the first mail, thank you. By the way, I don't think that the answer should be a simple yes: If a failure to configure might cause the system to be inaccessible over the net, the package maintainer has to take care to avoid this (i.e. ask a non-debconfized question in preinst, as glibc does). Regards, Frank -- Frank Küster Inst. f. Biochemie der Univ. Zürich Debian Developer
Bug#336771: ITP: nymbaron -- type III nymserver - get and send emails anonymously
Package: wnpp Severity: wishlist Owner: Laurent Fousse [EMAIL PROTECTED] * Package name: nymbaron Version : 0.0.20050507 Upstream Authors : Laurent Fousse [EMAIL PROTECTED], Jean-René Reinhard [EMAIL PROTECTED]. * URL : http://www.komite.net/laurent/soft/nymbaron * License : MIT/X Description : type III nymserver - get and send emails anonymously A nymserver is a mail server which stores emails on behalf of anonymous users. It provides long-term pseudonymous identities which can receive and send emails through the server, without revealing the user controling those identities. . This nymserver is built upon the mixminion remailer network. . WARNING: this is still considered alpha quality software. Do NOT use it if you require strong anonymity. . This package contains client and server binaries. . Homepage: http://www.komite.net/laurent/soft/nym3/ signature.asc Description: Digital signature
Re: postinst scripts failing because a new conffile wasn't accepted: Is it a bug?
[Frank Küster] assume that an update to a package brings in a changed conffile, and because the local admin had changed the conffile, he is asked, and he refuses to accept the changed version. Because one of the changes in the new version was crucial for the function of the program, the postinst script fails to initialize it, and the whole installation process fails. My proposal to avoid such problem is to implement multilevel configuration, where the package default configuration and the local overrides are stored in separate files, making sure local configuration do not affect changes to the package default, and thus no question is asked during upgrade. I talked a bit about this during debconf5. Have a look at URL:http://meetings-archive.debian.net/pub/debian-meetings/2005/debconf5/mpeg/2005-07-12/06-Writing_Enterprise_Ready_Software-Petter_Reinholdtsen.mpeg and URL:http://meetings-archive.debian.net/pub/debian-meetings/2005/debconf5/mpeg/2005-07-16/12-Debian_Edu_Upgrading_a_Preconfigured_CDD-Petter_Reinholdtsen.mpeg, as well as the slides available from URL:http://wiki.debian.org/?DebConf5Talks. Moving tetex to such mechanism would require some work. :) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Dummy packages and metapackages (call for consistency in the descriptions)
On Mon, 31 Oct 2005, Andreas Tille wrote: The meta packages builded by cdd-dev for instance contain data for building user menus which might override the menu entries of the dependant packages for the special purpose. This is definitely something else than debian/control but sounds to me definitely well placed in this kind of packages. Moreover the package might contain extra documentation for the dependant packages which seems to be reasonable in the meta package context. IMHO, drop the Meta prefix, then. There is no shame in doing so. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Dummy packages and metapackages (call for consistency in the descriptions)
On Tue, 1 Nov 2005, Henrique de Moraes Holschuh wrote: IMHO, drop the Meta prefix, then. There is no shame in doing so. Well, just dropping the meta is a little bit to simple. There is an extensive documentation about the Custom Debian Distribution techniques and the tools that are used at http://people.debian.org/~tille/cdd/ It makes IMHO no sense to invent just another prefix in front of package instead of meta just because there might be some additional (optional) information inside these packages which is not contained in debian/control, but reasonably is called meta information for the relevant task. It makes no sense to play wording games just because there are some people who think that the definition we gave on http://people.debian.org/~tille/cdd/ch-technology.en.html#s-metapackages does not fit into the scope they would give the name meta package. Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Are pure virtual Depends/Recommends entries bugs?
As I'm sure everyone knows, pure virtual entries in a Depends line are strongly deprecated, due to the fact that frontends have a tendency to pick a random provider of the package. What I'm not sure is if this is just ugly or actually considered a bug. In particular, I can't remember and would like to know: (a) Is a pure virtual entry with no prior alternative in a Depends line an actual bug? i.e., do we have a consensus on this? (b) If the answer to (a) is yes, is a pure virtual *Recommendation* a bug? Rationale: Recommendations are intended to be installed by default, so their fields should be just as friendly to automatic tools as Depends is. Daniel signature.asc Description: Digital signature
Re: Best practices on system users and groups
On Tue, 1 Nov 2005 04:53:33 -0500, sean finney [EMAIL PROTECTED] wrote: if you're going to do this, it would be better to provide a program or a shell library that is sourced in the postinst, and then awrapper function which does all of this. I would be willing to accept patches for the adduser package (either for the adduser script itself or for additional scripts) to solve this. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber |Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom | http://www.zugschlus.de/ Nordisch by Nature | Lt. Worf, TNG Rightful Heir | Fon: *49 621 72739834
Re: Dummy packages and metapackages (call for consistency in the descriptions)
On Tue, 01 Nov 2005, Andreas Tille wrote: does not fit into the scope they would give the name meta package. Well, I'd expect meta packages to have nothing on them and I'd be surprised to find relevant data inside them. If you have to keep that meta, you'd better do some work on the package descriptions to make sure they make it very clear that the package has data inside it (other than packaging metadata, that is). This avoids bad surprises for others like me, that are used to meta-packages being packages of packaging system metadata only. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Transition control
#include hallo.h * Simon Richter [Mon, Oct 31 2005, 07:00:43PM]: Hi, Eduard Bloch schrieb: Yep. What about another crazy idea... why not check the expected impact from a certain package update before a package has been accepted in _Unstable_? So katie could just veto a version change automaticaly before it too much mess is created, even (or especially) in Unstable. How about doing that via the autobuilders and experimental? I've been thinking about it for some time, and my proposal would be (indentation No, it is not the same thing. What you propose is simply declaring Experimental as playground for transitions, with some mechanisms to detect/guess possibly expected transitions and automate them. However I cannot see how it is supposed to solve the underlying problems. Basically it is the same method just splitted into the brave unstable and the transition merge area in Experimental which OTOH makes the real (integration) testing more complicated. It also gives Experimental a new purpose, conflicting with the current one, so this transition playground needs to be a separate branch. What I suggested is forcing more sanity on the side of maintainers, a simple mechanisms which forces the critical things to be thought trough twice. That would be a solution between the two extremes: - all power to one package maintainer (current situation) - comaintainers requirement for every package (discussed here a while ago, that looked good at the first glance but would not be effective enough and create overhead at wrong places) Eduard. -- Zathras: Zathras is used to being beast of burden to other people's needs. Very sad life... probably have very sad death, but at least there is symmetry. -- B5 -- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Packages file missing from unstable archive
On Thu, Oct 27, 2005 at 10:06:22AM +0200, Robert Lemmen wrote: On Wed, Oct 26, 2005 at 09:15:38PM -0400, Joey Hess wrote: (And yes, we still need a solution to speed up the actual deb file downloads..) [..] if zsync would be taught to handle .deb files as it does .gz files, and a method for apt be written, how big are the chances that support could be integrated into dak? the effort wouldn't be *that* big... I did a pretty unscientific test with apt and the changes from 0.6.41 - 0.6.42.1. It contains a good mix of code changes, documentation updates and translation updates [1]. With the two normals debs I got no effect at all because no usable data was found. I then repacked the data.tar.gz and control.tar.gz inside the deb with --rsyncable (and reassmbled the deb). This resulted in: Read apt_0.6.41_i386.deb. Target 0.8% complete. So this didn't had a lot of effect either. My next test was to use only the data.tar.gz of the two archives. Zsync will extract the gzip file then and use the tar as the base. With that I got: 8 Read data.tar.gz. Target 34.1% complete. used 1056768 local, fetched 938415 8 The size of the data.tar.gz is 1210514. A problem is that zsync needs to teached to deal with deb files (that is, that it needs to unpack the data.tar and use that for the syncs). Having it inside dak is not (at the beging) a requirement. Zsync seems to be able to deal with URLs, so we could create a pool with zsync files on any server and let them point to ftp.debian.org. We need to guarantee that the md5sum of the synced deb must match the md5sum in the Packages file. Initial tests indicate that that is not the case. Only the md5sum of the unpacked data.tar file matches, not from the gzip file (or the deb). This is a serious showstoper IMHO. Cheers, Michael [1] I would love to hear results from other people testing it with different packages and different changes. -- Linux is not The Answer. Yes is the answer. Linux is The Question. - Neo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: postinst scripts failing because a new conffile wasn't accepted: Is it a bug?
Scripsit Frank Küster [EMAIL PROTECTED] Henning Makholm [EMAIL PROTECTED] wrote: 4. User selects the No, I'm happy with my own version as it look now menu option. Your proposal, if I understand you correctly, is to make (4) result in the postinst failing even though the user _has_ taken care of the problem. You must have misunderstood me. I don't check whether the installed file is the one I expect; I simply run fmtutil --all - and that will fail if he hasn't solved the problem. Ah. I read your proposal as if you wanted to somehow intercept the user's answer and explicitly bail out from the postinst if the user is asked, and he refuses to accept the changed version. Of course it is not a bug if the package fails because the admin does not properly adjust his conffiles. So finally there is one person who simply says yes to the question in the first mail, thank you. By the way, I don't think that the answer should be a simple yes: If a failure to configure might cause the system to be inaccessible over the net, the package maintainer has to take care to avoid this (i.e. ask a non-debconfized question in preinst, as glibc does). Generally, I think that we depend on the user who has chosen to change a conffile himself to also be able to judge correctly whether a maintainer-supplied change is relevant to him or not. Though this assumption is often wrong, it is the best thing we have in general. It is of course reasonable to be more paranoid than that in situations where failure can impair one's ability to fix things later. In the long run, the user-friendly solution is probably to offer (via a debconf question that defaults to 'yes') to automatically rewrite the conffile to take the change into account. In the case you're presenting here it seems that it ought to be doable by search-and-replace. The offer should only be made if the conffile has actually changed *and* it mentions the old variable names *and* one is upgrading from an older version. -- Henning MakholmWe can hope that this serious deficiency will be remedied in the final version of BibTeX, 1.0, which is expected to appear when the LaTeX 3.0 development is completed.
Re: Transition time: KDE, JACK, arts, sablotron, unixodbc, net-snmp, php, ...
On Tue, Nov 01, 2005 at 12:41:09PM +0100, Henning Makholm wrote: So, would anybody object if I set up a cronjob that emails the PTS whenever a (source) package propagates to, or is removed from, testing? I won't so nobody'd object; but it's one of the things we agreed we wanted at the Vancouver meeting. I think there was going to be a -testing-changes list or something, perhaps? I forget exactly. Cheers, aj signature.asc Description: Digital signature
Re: Transition time: KDE, JACK, arts, sablotron, unixodbc, net-snmp, php, ...
On Tue, Nov 01, 2005 at 11:00:46AM +0100, Henning Makholm wrote: No it's not. RC bug, still in testing - fixing this is very important, because it may hold up the testing migration of other packages. RC bug, not in testing - fixing this only affects this one package, and is therefore not so urgent. If the package isn't in testing, anything that depends on it isn't either, so you can still be affecting more than one package. Also, the above talks about its effect on other maintainers; you might also consider the effect on (potential) users of your package: in the former case fixing this isn't that important, because users can just use the version in testing, while the latter is fixing this is very important, because users don't have any recent version to use. Personally, I'd go for RC bug - fixing this is very important and urgent, and end there, though. Maybe it helps to look at it this way: testing tries to match unstable, while filtering out the crap; the more crap there is in unstable the harder that is and the more likely it is the filter will get clogged. Cheers, aj signature.asc Description: Digital signature
Re: Transition time: KDE, JACK, arts, sablotron, unixodbc, net-snmp, php, ...
Anthony Towns aj@azure.humbug.org.au wrote: On Tue, Nov 01, 2005 at 12:41:09PM +0100, Henning Makholm wrote: So, would anybody object if I set up a cronjob that emails the PTS whenever a (source) package propagates to, or is removed from, testing? I won't so nobody'd object; but it's one of the things we agreed we wanted at the Vancouver meeting. I think there was going to be a -testing-changes list or something, perhaps? I forget exactly. For sure I won't read a -testing-changes list, but still I am interested in when one of *my* packages, or the ones I'm specifically interested in, enter or leave testing. So a mail to the PTS would be much better, I think. Regards, Frank -- Frank Küster Inst. f. Biochemie der Univ. Zürich Debian Developer
Re: postinst scripts failing because a new conffile wasn't accepted: Is it a bug?
Henning Makholm [EMAIL PROTECTED] wrote: In the long run, the user-friendly solution is probably to offer (via a debconf question that defaults to 'yes') to automatically rewrite the conffile to take the change into account. That can only be done if we change our policy with respect to maintainer scripts changing of conffiles; and that I would not want unless something like ucf does is integrated in dpkg. Regards, Frank -- Frank Küster Inst. f. Biochemie der Univ. Zürich Debian Developer
Bug#336852: ITP: libfacile-dev -- functional constraint library implemented in objective caml
Package: wnpp Severity: wishlist Owner: Steffen Joeris [EMAIL PROTECTED] I think the lib is needed by some kde applications. The Kalzium developer told me that this lib is needed during the build of Kalzium. * Package name: libfacile-dev Version : 1.1 Upstream Author : Copyright (C) 2001, CENA * URL : http://www.recherche.enac.fr/opti/facile * License : GNU Lesser General Public License Description : functional constraint library implemented in objective caml FaCiLe is a constraint programming library over integer finite domain written in Objective Caml. It offers all usual facilities to create and manipulate finite domain variables, arithmetic expressions and constraints (possibly non-linear), built-in global constraints and search goals. FaCiLe allows as well to build easily user-defined constraints and goals (including recursive ones), making pervasive use of OCaml higher-order functionals to provide a simple and flexible interface for the user. As FaCiLe is an OCaml library and not yet another language, the user benefits from type inference and strong typing discipline, high level of abstraction, modules and objects system, as well as native code compilation efficiency, garbage collection and replay debugger, all features of OCaml (among many others) that allow to prototype and experiment quickly: modeling, data processing and interface are implemented with the same powerful and efficient language. . Web site: http://www.recherche.enac.fr/opti/facile -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.12-1-686 Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Transition time: KDE, JACK, arts, sablotron, unixodbc, net-snmp, php, ...
Scripsit Henning Makholm [EMAIL PROTECTED] So, would anybody object if I set up a cronjob that emails the PTS whenever a (source) package propagates to, or is removed from, testing? It turns out that PTS mail does not ordinary get sent to the maintainer address, only to third-party subscribers. So I should rephrase: Would anybody object if my cronjob emails the PTS *and* the maintainer address? -- Henning Makholm The compile-time type checker for this language has proved to be a valuable filter which traps a significant proportion of programming errors. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Transition time: KDE, JACK, arts, sablotron, unixodbc, net-snmp, php, ...
Op di, 01-11-2005 te 18:21 +0100, schreef Henning Makholm: Scripsit Henning Makholm [EMAIL PROTECTED] So, would anybody object if I set up a cronjob that emails the PTS whenever a (source) package propagates to, or is removed from, testing? It turns out that PTS mail does not ordinary get sent to the maintainer address, only to third-party subscribers. So I should rephrase: Would anybody object if my cronjob emails the PTS *and* the maintainer address? Why do it that way? If you set up a cron job that only mails to the PTS (to a new keyword, one that by default sends to the maintainer address), then maintainers can disable those mails if they want to. I suggest to make this opt-out, because those mails are about something which has a very real and direct implication on the usefulness of your package to your users; but if there's a lot of objection, surely you could make it opt-in and announce it on -devel-announce? -- The amount of time between slipping on the peel and landing on the pavement is precisely one bananosecond -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: is the Debian mail server healthy?
Marc Haber wrote: On Sun, 30 Oct 2005 16:34:49 +0100, Stig Sandbeck Mathisen [EMAIL PROTECTED] wrote: On Oct 30, 2005, at 10:52, Marc Haber wrote: I can confirm that master sits on some messages for days, such as this one, for example: |Received: from master.debian.org ([146.82.138.7]) |by torres.zugschlus.de with esmtp (Exim 4.54) |id 1EVmC6-lm-8a |for [EMAIL PROTECTED]; Sat, 29 Oct 2005 10:36:07 +0200 |Received: from qa by master.debian.org with local (Exim 3.35 1 (Debian)) |id 1EUOw2-0003y4-00; Tue, 25 Oct 2005 08:33:50 -0500 So, there might be a problem, because these things happen quite regularly in the last few weeks. That does not mean that master has not tried to deliver it to you during these days. If it didn't try, it's broken. torres was available all the time and was actually receiving mail. On a related note, the list archives are not working right. Steve Langasek's latest message to debian-devel-announce hasn't shown up in the archives at all. 'serious' bug filed against listarchives, but maybe someone reading this will know a faster way to check this out. -- ksig --random| -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Sorting source packages to reduce build effort
Peter Samuelson wrote: [Daniel Ruoso] The question is: Is there a way (I mean, already implemented) to sort the packages putting the most used and less dependencies on the front and showing wich packages needs to be installed before the build can start? [Goswin von Brederlow] No. :( Sounds like a job for tsort, with input from apt-rdepends -b or similar, driven by random scripting. Tried to write such a thing, but apt-rdepends -b was segfaulting. -- ksig --random| -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Help: Bug#336469: pure-ftpd uninstallable : no pure-ftpd-common
Steve Langasek wrote:
On Tue, Nov 01, 2005 at 09:27:06AM +0100, Henning Makholm wrote:
Scripsit Steve Langasek [EMAIL PROTECTED]
No, it's a bug in dpkg-dev, which should know how to set
${Source-Version} correctly for binNMUs.
I'm not clear which file actually puts this substitution in substvars; I
tried to track it down but couldn't find it. Clearly whatever file does
that should provide two variables (Source-Version and Binary-Version are
indeed better names than I was thinking of). If I found the file, I'd
write and submit a patch.
It can't really know, can it? If I have a control file with
Package: foo
Architecture: any
Package: foo-data-extra
Architecture: all
Package: foo-plugins
Architecture: any
Depends: foo (=${Source-Version}), foo-data-extra (=${Source-Version})
then a binNMU ought to have foo-plugins depend on the binNMU'ed
version of foo, but on the common version of foo-data-extra.
If dpkg-gencontrol were to figure out that, it would need to parse a
lot of data that it currently doesn't. And even if it did it
correctly, the resulting behavior would be confusing.
IMO it would be better to split ${Source-Version} into two substvars,
one of which includes binNMU suffixes and one of which doesn't.
Yes; sorry, I thought it was self-evident that Source-Version ought to
refer to the *source* version, and that a new variable name is called for
where the binary version is needed.
Right. Hmm.
--
ksig --random|
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#336698: dh_strip: debug data going to the wrong place
Steve Langasek wrote: Sorry, you're completely wrong. The files installed in /usr/lib/debug/usr/lib are detached symbol files, that are loaded automatically by gdb -- *not* using LD_LIBRARY_PATH; and gdb looks for detached symbol files by prepending /usr/lib/debug to the full path of the original object file. So there's no debhelper bug here. If there are detached symbol files that aren't working, that bug must lie elsewhere. Hmm. Then what are those files in /usr/lib/debug (not /usr/lib/debug/path)? I always thought those were the detached symbol files, but I guess they must be something else -- what? -- ksig --random| -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: ITP: pcmciautils -- PCMCIA userspace utilities (Linux 2.6.13+)
On Sun, Jul 31, 2005 at 07:00:37PM +0200, Per Olofsson wrote: retitle 319583 ITP: pcmciautils -- PCMCIA userspace utilities (Linux 2.6.13+) thanks I'm the maintainer of pcmcia-cs so I'm intending to package pcmciautils. May I ask for the status of this ITP? Greetings Marc -- - Marc Haber | I don't trust Computers. They | Mailadresse im Header Mannheim, Germany | lose things.Winona Ryder | Fon: *49 621 72739834 Nordisch by Nature | How to make an American Quilt | Fax: *49 621 72739835 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#336698: dh_strip: debug data going to the wrong place
On Tue, Nov 01, 2005 at 02:12:04PM -0500, Nathanael Nerode wrote: Steve Langasek wrote: Sorry, you're completely wrong. The files installed in /usr/lib/debug/usr/lib are detached symbol files, that are loaded automatically by gdb -- *not* using LD_LIBRARY_PATH; and gdb looks for detached symbol files by prepending /usr/lib/debug to the full path of the original object file. So there's no debhelper bug here. If there are detached symbol files that aren't working, that bug must lie elsewhere. Hmm. Then what are those files in /usr/lib/debug (not /usr/lib/debug/path)? I always thought those were the detached symbol files, but I guess they must be something else -- what? Those are real libraries that were not stripped, and those should go away in favour of the detached version. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Help: Bug#336469: pure-ftpd uninstallable : no pure-ftpd-common
Nathanael Nerode wrote:
Scripsit Steve Langasek [EMAIL PROTECTED]
No, it's a bug in dpkg-dev, which should know how to set
${Source-Version} correctly for binNMUs.
I'm not clear which file actually puts this substitution in substvars; I
tried to track it down but couldn't find it. Clearly whatever file does
that should provide two variables (Source-Version and Binary-Version are
indeed better names than I was thinking of). If I found the file, I'd
write and submit a patch.
dpkg-dev: /usr/lib/dpkg/controllib.pl
Cheers
T.
--
Thomas Viehmann, http://thomas.viehmann.net/
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Transition time: KDE, JACK, arts, sablotron, unixodbc, net-snmp, php, ...
Steve Langasek wrote: On Mon, Oct 31, 2005 at 02:54:49PM -0500, Nathanael Nerode wrote: The enormous ABI transitions have been particularly hard, of course. If we can avoid ABI-breaking transitions in the future it would help. :-) Wholly unrealistic. Libraries *do* undergo ABI changes; there are only a handful of library upstreams who know how to write a library interface that's proofed against future design decisions, and in most cases it's not worth the effort to try to write libs this way Perhaps I didn't make myself clear. I wasn't actually thinking of those, since those can be handled quite nicely: if the library changes soname and the symbols are versioned, both old and new versions can (and should) coexist in separate packages and such transitions generally move pretty smoothly (albeit slowly due to absent maintainers and lack of NMUs, which is a different problem -- there simply should not have been that many packages still depending on libpng10 when it was removed.) (At least for libraries with more than a few reverse depends; for those with very few, they and their reverse depends can comfortably be pushed in simultaneously if there's some maintainer coordination on lib transitions.) -- and it wouldn't save us from C++ ABI changes anyway. Now *that* was the sort of ABI change I was hoping we could avoid having every release. A major C ABI change would be even worse. I think making a queue for transitions, so that they're basically one at a time, would solve most remaining problems. Doesn't work when lib maintainers don't coordinate. Well, indeed, which was kind of, um, what I just said. Making a queue for transitions is a subset of lib maintainers coordinating. A better option is to make britney more resilient in dealing with library transitions by keeping old binary packages around in testing instead of requiring them to be removed at the same time as the new version enters, which removes the need for all packages to be ready to enter testing at the same time. This has been on the TODO list since it was discussed this past March in Vancouver, and is currently the top item on Anthony Towns' britney hacking list at http://www.erisian.com.au/market/. The old source packages have to remain on the servers too in order to satisfy license requirements; hope someone noticed that. (Hmm, I wish there was a way there to pay him to change the priorities -- what britney needs most is proper version tracking support for its RC bug analysis, and I'd give some money for that; that's not listed in the notes for 'next round of version tracking support' under debbugs either.) Anyway, such a change won't do anything to help the people trying to install 'testing' * when the new library uses the same package name as the old, so users can't install packages depending on the old and the new at the same time (hence different package names) * when it Conflicts: with the old, giving the same result (hence different sonames; also different ports for different wire protocols, etc.) * or when both can end up linked into the same binary with conflicting symbols, causing crashes and misbehavior (hence versioned symbols) If these issues aren't fixed, britney changes will just make 'testing' more broken; imagine having two wire-incompatible binary packages of JACK, trying to run on the same port, available in 'testing'. In most cases, fixes for all three of these problems, as noted, can be done right now, without any britney support, by package maintainers, or at least by upstream. And if they are done, they remove much if not all of the motivation for the britney changes. So I guess I'm saying I'd rather concentrate on versioned symbols, proper soname handling, and supporting coexisting old and new versions for heavily used libraries; this will make more difference than any change in britney. And when that doesn't suffice, library maintainers need to coordinate with the release team. -- ksig --random| -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Transition time: KDE, JACK, arts, sablotron, unixodbc, net-snmp, php, ...
Henning Makholm wrote: Well, the build-dependencies became fixed about 4 days ago (courtesy of a NMU by yours truly). Is 4 days enough to get something removed from testing? Well, if you're curious, in this case autotrace had to be removed because pstoedit had to be removed, and pstoedit had to be removed because it had acquired a dependency on new gcc-4.0, and it seemed like a bad idea to hold up the monster transition for new gcc-4.0 when new gcc-4.0 depends on new binutils and new glibc, both of which have multiple grave bugs. Automatic notice to the maintainers is a good idea, of course; didn't I hear elsewhere on the thread that someone was implementing it? :-) -- ksig --random| -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: postinst scripts failing because a new conffile wasn't accepted: Is it a bug?
Petter Reinholdtsen wrote: My proposal to avoid such problem is to implement multilevel configuration, where the package default configuration and the local overrides are stored in separate files, making sure local configuration do not affect changes to the package default, and thus no question is asked during upgrade. This is best design, certainly, but can be rather difficult to do if upstream is not using a cooperative mechanism. In contrast, if upstream has DTRT, this should require no maintainer work. Oh well. -- ksig --random| -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Evolution Contacts
hey, Someone sent an email I dunno if here or in evolution-hackers ML but I also lost All my contacts after upgrading yesterday in Sid! ;0( ;-( .Alejandro -- Open WebMail Project (http://openwebmail.org) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Best practices on system users and groups
On Tue, Nov 01, 2005 at 11:14:59AM +0200, Lars Wirzenius wrote: Also, sticking all the tens of lines of boilerplate code into the postinst of every package that needs a system user is a good way to invite trouble. When the boilerplate has a bug (possibly because things change in the future), it will have to be fixed in dozes on of packages. It's oh so much more sensible to create a tool that postinsts can call: if boilerplate code is good enough, then it can easily be abstracted away. I'm aware of that, but currently there's lot of packages that do it wrong in any case, so having some boilerplate script they can be pointed to is something good. Obviously, it would be best if this was provided as shell functions that could be sourced by package's maintainer scripts. But that's the second step, first lets document it properly, then implement it, and then remove the code from the document and point to the implementation. Regards Javier signature.asc Description: Digital signature
Re: Best practices on system users and groups
On Tue, Nov 01, 2005 at 11:14:59AM +0200, Lars Wirzenius wrote: ma, 2005-10-31 kello 22:03 +0100, Javier Fernández-Sanguino Peña kirjoitti: After the feedback of the recent d-d thread, I've adapted the section I wrote on the best practices related to system users and groups, it is currently available at: http://www.debian.org/doc/manuals/developers-reference/ch-best-pkging-practices.en.html#s-bpp-lower-privs I would like developers to review and provide feedback for that section, specially in form of patches. I'm considering doing a bug hunt for: DON'T do this: addgroup --quiet --system $SERVER_GROUP 2/dev/null ||true When (not if!) addgroup fails, the poor system administrator gets no indication of it. This is a bug, and a pretty bad one. FWIW, that's partially based on what some package's postinst do (exim4-base, fetchmail, ntp-simple, and proftp, for example). I've fixed the sample code to not redirect error messages (that probably should have been a '/dev/null' and removed the '|| true' too. If adduser isn't quiet enough with --quiet, then fix that, don't hide real errors. Remove both the redirect and the || true. Done in CVS. Javier signature.asc Description: Digital signature
Re: Best practices on system users and groups
On Tue, Nov 01, 2005 at 11:10:19AM +0100, Olaf van der Spek wrote: ma, 2005-10-31 kello 22:03 +0100, Javier Fernández-Sanguino Peña kirjoitti: I would like developers to review and provide feedback for that section, specially in form of patches. I'm considering doing a bug hunt for: Typically this means that the configuration files are owned by group, belong to the group of the system user and are mode 0640. Owned by group? What group? The system group. If the daemon logs to a directory under /var/log/ then *it* should be owned by the system user and rotated log files need not be changed ownership. What does *it* mean? The directory or the log file? The directory. I've made some changes in CVS to clarify those. Thanks Javier signature.asc Description: Digital signature
Re: Best practices on system users and groups
On Tue, Nov 01, 2005 at 04:53:33AM -0500, sean finney wrote: hi javier, On Mon, Oct 31, 2005 at 10:03:01PM +0100, Javier Fernández-Sanguino Peña wrote: I would like developers to review and provide feedback for that section, thanks for actually putting this into a document, however, i notice two problems: - the addgroup/adduser functions mask the error status, yet do not later check to see if the group was actually created. this is doubly Fixed in CVS. the second thing i notice is that you arbitrarily modify the user in question via usermod, which would override the local admin's changes. i wonder whether it is even good to recommend this at all. Usermod is only called if the user does not exist and the package creates it. gdm, postgresql and logcheck already do this. In the example code, if the system user exists, then usermod is not called, which is better than what logcheck or postgresl currently do. i'd like to double-ack this remark. even if the oft-mentioned dh_user were implemented, if there were a bug in this implementation, every affected package would have to be /rebuilt/ if the buggy code were actually in the postinsts. if you're going to do this, it would be better to provide a program or a shell library that is sourced in the postinst, and then awrapper function which does all of this. Yes, that's what I'm currently more inclined at. I'm not certain which package should provide this function but adduser seems like a valid candidate for that. Regards Javier signature.asc Description: Digital signature
Re: Best practices on system users and groups
On Tue, Nov 01, 2005 at 12:14:58PM +0100, Jonas Meurer wrote: On 31/10/2005 Javier Fernández-Sanguino Peña wrote: After the feedback of the recent d-d thread, I've adapted the section I wrote on the best practices related to system users and groups, it is currently available at: http://www.debian.org/doc/manuals/developers-reference/ch-best-pkging-practices.en.html#s-bpp-lower-privs the group deletion has currently a problem. From 6.5.1.3 'Removing system users': (...) first, the 'if [ -n $FIST_USER_GID ] then' should better be 'if [ -n $FIRST_USER_GID]; then' (two small typos). Fixed in CVS. Actually, the $FIST typo was in other places as well. second, and more important, the default GID for the group 'users' is 100 for adduser, so the check above will always fail. system groups created via 'addgroup --system' have GIDs between 100 and 199. Hmm.. You are right. That's not properly documented, I assumed USERS_GID was not used for system users but it is. in my eyes it would be more sane to check for FIRST_SYSTEM_GID instead of USERS_GID. There was no FIRST_SYSTEM_GID in my adduser.conf file (probably because of an upgrade, when was this one introduced?), and it's not documented in the manpage so I missed it. of my adduser.conf file). I've changed the code in CVS to use both FIRST_SYSTEM_GID and LAST_SYSTEM_GID (and to define them if not present) and adjusted the delgroup code to make it similar to the deluser code. Thanks for the comments Javier signature.asc Description: Digital signature
Re: Transition time: KDE, JACK, arts, sablotron, unixodbc, net-snmp, php, ...
* Anthony Towns (aj@azure.humbug.org.au) [051101 17:23]: On Tue, Nov 01, 2005 at 12:41:09PM +0100, Henning Makholm wrote: So, would anybody object if I set up a cronjob that emails the PTS whenever a (source) package propagates to, or is removed from, testing? I won't so nobody'd object; but it's one of the things we agreed we wanted at the Vancouver meeting. I think there was going to be a -testing-changes list or something, perhaps? I forget exactly. We agreed to both maintainer mails (but PTS might be more appropriate for that), and a summary to -testing-changes. IOW, whoever shows code up for any of the tasks has some bonus points :) Cheers, Andi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#336971: please order posts to a single bugreport by date/thread
Package: bugs.debian.org Severity: minor Today bugs.debian.org had some problem in receiving mails to [EMAIL PROTECTED] timely. For example, in a discussion I started on #222138, mails reached b.d.o in a non-causal order, making the bug report difficult to follow on the web page. Conversely, reading it downloading the mbox folder and using, for example, mutt sorting the thread by date or thread is nice and easy to follow. I'm thus wondering: is it possible to sort the various posts to [EMAIL PROTECTED] as seen on the web by date (or thread, or whatever) as many MUA do? All the needed information seem to be already there. Many thanks in advance, Cheers. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.14-1-686 Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#336978: ITP: frown -- a parser generator for Haskell 98
Package: wnpp Severity: wishlist Owner: Arjan Oosting [EMAIL PROTECTED] * Package name: frown Version : 0.6 Upstream Author : Ralf Hinze [EMAIL PROTECTED] * URL : http://www.informatik.uni-bonn.de/~ralf/frown/index.html * License : GPL version 2 Description : parser generator for Haskell 98 Frown is an LALR(k) parser generator for Haskell 98 written in Haskell 98. . Its salient features are: - The generated parsers are time and space efficient. On the downside, the parsers are quite large. - Frown generates four different types of parsers. As a common characteristic, the parsers are genuinely functional (ie `table-free'); the states of the underlying LR automaton are encoded as mutually recursive functions. Three output formats use a typed stack representation, one format due to Ross Paterson (code=stackless) works even without a stack. - Encoding states as functions means that each state can be treated individually as opposed to a table driven-approach, which necessitates a uniform treatment of states. For instance, look-ahead is only used when necessary to resolve conflicts. - Frown comes with debugging and tracing facilities; the standard output format due to Doaitse Swierstra (code=standard) may be useful for teaching LR parsing. - Common grammatical patterns such as repetition of symbols can be captured using rule schemata. There are several predefined rule schemata. - Terminal symbols are arbitrary variable-free Haskell patterns or guards. Both terminal and nonterminal symbols may have an arbitrary number of synthesized attributes. - Frown comes with extensive documentation; several example grammars are included. . Furthermore, Frown supports the use of monadic lexers, monadic semantic actions, precedences and associativity, the generation of backtracking parsers, multiple start symbols, error reporting and a weak form of error correction. A preliminary version of this package will soon be available on http://moonshine.dnsalias.org/debian/unstable Greetings, Arjan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Debian based GNU/Solaris: pilot program
Nexenta OS: Debian based GNU/Solaris == This is to announce Nexenta: the first-ever distribution that combines GNU and OpenSolaris. As you might know, Sun Microsystems just opened Solaris kernel under CDDL license, which allows one to build custom Operating Systems. Which we did... created a new Debian based GNU/Solaris distribution with (the latest bits of) Solaris kernel core userland inside. We'll open Nexenta web developer portal completely for the general public by mid-November. Today we are launching a Pilot Program. Debian developers and the entire Debian community - you are welcome to participate in the Pilot! What is Nexenta OS today = Several things: 1) A working prototype that runs on our 32-bit laptops and AMD64 box; the latter is used for development of the system itself, and it in turn runs our entire development environment, and hosts the web portal (below). 2) 2,300 Debian packages available for immediate usage. 3) Developer's portal at http://www.gnusolaris.org - fully functional, with downloads, APT repository, discussion forums, developer's hack zone, bug database, blogs, and numerous Solaris and free software related resources. This will be 100% open and free-of-any-charge easy-to-install easy-to-use distribution. Coming out soon! The Future === We do hope that at some point, sooner rather than later, our changes (so far for the most part just cleanups to build the DEBs in the new Solaris-like environment) will be integrated with the upstream. At the end of the day - this would be the right thing to do. For Developers == There are probably very few projects that can come anywhere close to Nexenta OS, in terms of the size, complexity and openness. The Nexenta project offers a rare opportunity to take part in something as big as this mega-project at its early stage - and make a meaningful contribution, ranging from selected improvements and up to... well, the sky's the limit. One thing that makes it not only challenging but also a rewarding experience is - the kernel. It's a true UNIX (Solaris fully complies to The Open Group specifications). It's very stable, extremely development-friendly, well documented, cleanly architected, and well written. Contact = If interested, please send e-mail to support at nexenta.com, and tell us a few words about yourself. We'll respond with a user/password. Thanks! Nexenta Team support at nexenta.com www.gnusolaris.org -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian based GNU/Solaris: pilot program
On Tue, Nov 01, 2005 at 06:21:45PM -0800, Alex Ross wrote: 2) 2,300 Debian packages available for immediate usage. [...] There are probably very few projects that can come anywhere close to Nexenta OS, in terms of the size, 2300 15000, by my reckoning. and openness. You keep using that word. I do not think it means, what you think it means. If interested, please send e-mail to support at nexenta.com, and tell us a few words about yourself. We'll respond with a user/password. Not to poop on your parade, but please, next time you go to announce something to a technical list like d-devel -- drop the marketing guff, just stick to the useful info. - Matt signature.asc Description: Digital signature
Re: Debian based GNU/Solaris: pilot program
Matthew Palmer wrote: On Tue, Nov 01, 2005 at 06:21:45PM -0800, Alex Ross wrote: words about yourself. We'll respond with a user/password. Not to poop on your parade, but please, next time you go to announce something to a technical list like d-devel -- drop the marketing guff, just stick to the useful info. I found this email and comment rude. I can't get into my head that people from community and people moving and doing open source things can become or even give out this kind of rude comments. I don't know if Alex works for Sun, but in anyway, he has the freedom and option to express himself as he wishes. Your comments, only bring FUD. 3x *shrug* .Alejandro - Matt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian based GNU/Solaris: pilot program
On Wed, 2005-11-02 at 14:24 +1100, Matthew Palmer wrote: On Tue, Nov 01, 2005 at 06:21:45PM -0800, Alex Ross wrote: 2) 2,300 Debian packages available for immediate usage. [...] There are probably very few projects that can come anywhere close to Nexenta OS, in terms of the size, 2300 15000, by my reckoning. very true. but Nexenta OS is not just number of packages. it also brings something totally new and exciting to the Debian world. ...and number of packages growes as we speak. So, it is just a matter of time. Most hard and exciting part is to achive acceptable level of integration between OpenSolaris Core and the rest of Debian world. Nobody did it before. So, it is sort of not for newbies. :-) Also this project requires *a lot of* hacking. To name a few, we are in progress of integration Project Utopia(hal, dbus, pmount), gst, FUSE, etc. Erast -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian based GNU/Solaris: pilot program
On Tue, Nov 01, 2005 at 09:07:08PM -0800, Erast Benson wrote: On Wed, 2005-11-02 at 14:24 +1100, Matthew Palmer wrote: On Tue, Nov 01, 2005 at 06:21:45PM -0800, Alex Ross wrote: 2) 2,300 Debian packages available for immediate usage. [...] There are probably very few projects that can come anywhere close to Nexenta OS, in terms of the size, 2300 15000, by my reckoning. very true. but Nexenta OS is not just number of packages. it also brings something totally new and exciting to the Debian world. I'm not discounting that it's new and exciting (I wouldn't say totally, but that's a matter of opinion), and I'm in fact quite interested in what the technical benefits of running Debian on a Solaris kernel might be for my needs. However, Alex did specifically claim that Nexenta was of unmatched size, and I was refuting that particular claim. ...and number of packages growes as we speak. So, it is just a matter of time. I'm actually quite surprised that you've only been able to build 2300 packages out of Debian, but I presume there's significant hurdles which I'd have trouble imagining standing in your way there. Most hard and exciting part is to achive acceptable level of integration between OpenSolaris Core and the rest of Debian world. Nobody did it before. So, it is sort of not for newbies. :-) Right. You want competent, clueful, technical people to work on the project. I suspect that these are the same people who are going to be turned off (as I was) by unashamed marketing speak. In fact, your message has gotten me far more interested in Nexenta than the original did, as I can see the sort of things that need to be done and might be interested in working on some of those. - Matt signature.asc Description: Digital signature
Re: Dummy packages and metapackages (call for consistency in the descriptions)
On Tue, 1 Nov 2005, Henrique de Moraes Holschuh wrote: Well, I'd expect meta packages to have nothing on them Why? Was there any other definition than the link I posted that leads to this assumption? Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Transition time: KDE, JACK, arts, sablotron, unixodbc, net-snmp, php, ...
On Tue, Nov 01, 2005 at 02:49:27PM -0500, Nathanael Nerode wrote: (Hmm, I wish there was a way there to pay him to change the priorities -- what britney needs most is proper version tracking support for its RC bug analysis, and I'd give some money for that; that's not listed in the notes for 'next round of version tracking support' under debbugs either.) No; proper version tracking in britney is *much* less important than fixing how we do library transitions. We have other means of tracking RC bug counts in testing and can easily override britney's concept of package bugginess if necessary, but library transitions are a major, and currently unavoidable, time sink for the release team. Anyway, such a change won't do anything to help the people trying to install 'testing' * when the new library uses the same package name as the old, so users can't install packages depending on the old and the new at the same time (hence different package names) which is rare; apt is the only package I know which does this for legitimate reasons. * when it Conflicts: with the old, giving the same result (hence different sonames; also different ports for different wire protocols, etc.) which is an issue for C++ ABI transitions, but the C++ ABI transition was not the only reason for this transition to be so difficult -- the KDE change wouldn't have been half as difficult if it had not been connected to a number of other, unrelated soname changes. * or when both can end up linked into the same binary with conflicting symbols, causing crashes and misbehavior (hence versioned symbols) which is a bug in those libraries that causes breakage on partial upgrades, and we should fix this regardless of what happens to britney. If these issues aren't fixed, britney changes will just make 'testing' more broken; imagine having two wire-incompatible binary packages of JACK, trying to run on the same port, available in 'testing'. No, this would not involve keeping multiple versions of the same binary package in testing; there would be no way to install the older versions anyway. We're only talking about keeping old binary packages around which are no longer available from the new source package, which is precisely the case that is at issue with library transitions. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: Debian based GNU/Solaris: pilot program
On Tue, Nov 01, 2005 at 09:32:49PM -0700, Alejandro Bonilla Beeche wrote: I don't know if Alex works for Sun, but in anyway, he has the freedom and option to express himself as he wishes. Your comments, only bring FUD. So I do *not* have the freedom and option to express myself as I wish? Interesting. However, you pass adverse comment on my adverse comment on Alex's post, and that is (apparently) acceptable. Well, I pass adverse comment on your adverse comment of my adverse comment, and I look forward to your adverse comment on my adverse comment on your adverse comment on my adverse comment about Alex's post. BTW, FUD does actually have a distinct meaning, it's not some catchall for BadWords. - Matt signature.asc Description: Digital signature
Re: Debian based GNU/Solaris: pilot program
On Wed, 2005-11-02 at 17:16 +1100, Matthew Palmer wrote: On Tue, Nov 01, 2005 at 09:07:08PM -0800, Erast Benson wrote: On Wed, 2005-11-02 at 14:24 +1100, Matthew Palmer wrote: On Tue, Nov 01, 2005 at 06:21:45PM -0800, Alex Ross wrote: 2) 2,300 Debian packages available for immediate usage. [...] There are probably very few projects that can come anywhere close to Nexenta OS, in terms of the size, 2300 15000, by my reckoning. very true. but Nexenta OS is not just number of packages. it also brings something totally new and exciting to the Debian world. I'm not discounting that it's new and exciting (I wouldn't say totally, but that's a matter of opinion), and I'm in fact quite interested in what the technical benefits of running Debian on a Solaris kernel might be for my needs. This is an interesting question. You could find more answers by reading materials at www.opensolaris.org. One could benefit from the fact that OpenSolaris development is more organized and centralized which leads to more tight control on its interfaces. In short, OpenSolaris interfaces are stable. That brings binary compatability across future OpenSolaris-based distros. Another obvious benefit is that OpenSolaris licensed under open sourced license which allowes to HW vendors to write their own drivers for all that variety of existing specific hardware and yet not to open their IP. But at the same time, this license(which is CDDL), Thecnical aspects benefits too. The kernel is *very* stable and highly QA'd by Sun Microsystems. It brings bunch of advanced technologies and complete(not just partial) implementations of many kernel interfaces. From user perspective, OpenSolaris core is well documented and supported. All that means: the end user of the system will not be forced to re-compile drivers during installations, will not suffer from half-implemented features, will not be forced to deal with source packages and will benefit from both world - proprietery and open source. Erast -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian based GNU/Solaris: pilot program
Matthew Palmer wrote: I'm not discounting that it's new and exciting (I wouldn't say totally, but that's a matter of opinion), and I'm in fact quite interested in what the technical benefits of running Debian on a Solaris kernel might be for my needs. However, Alex did specifically claim that Nexenta was of unmatched size, and I was refuting that particular claim. Hmm, did really I say unmatched?.. It's the size, *and* the early stage, *and* the fact that it runs all our stuffs, *and* the kernel. It's a combination. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Best practices on system users and groups
Usermod is only called if the user does not exist and the package creates it. gdm, postgresql and logcheck already do this. In the example code, if the system user exists, then usermod is not called, which is better than what logcheck or postgresl currently do. One very short notice for information: usermod recently got long options added, similarly to useradd/userdel. This happened in passwd 4.0.13-4 (all utilities in passwd are slowly getting GNU-style long options added) So, scripts calling it can use more readable options: [EMAIL PROTECTED]:~/src/debian/dl10n usermod -h Usage: usermod [options] LOGIN Options: -c, --comment COMMENT new value of the GECOS field -d, --home-dir HOME_DIR new login directory for the new user account -m, --move Use -m option to move data to the new directory -e, --expiredate EXPIRE_DATE set account expiration date to EXPIRE_DATE -f, --inactive INACTIVE set password inactive after expiration to INACTIVE -g, --gid GROUP force use GROUP as new initial login group -G, --groups GROUPS list of supplementary groups -a, --appendUse -a option to append the user to the supplemental groups -h, --helpdisplay this help message and exit -l, --new-login LOGIN new value of the login name -L, --locklock the user account -o, --non-unique allow using duplicate (non-unique) UID -p, --password PASSWORD use encrypted password for the new password -s, --shell SHELL new login shell for the user account -u, --uid UID new UID for the user account -U, --unlock unlock the user account Of course, this is currently possible only in unstable -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted gprolog 1.2.18-16 (source i386 all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Tue, 1 Nov 2005 08:15:20 + Source: gprolog Binary: gprolog gprolog-doc Architecture: source i386 all Version: 1.2.18-16 Distribution: unstable Urgency: low Maintainer: Salvador Abreu [EMAIL PROTECTED] Changed-By: Salvador Abreu [EMAIL PROTECTED] Description: gprolog- GNU Prolog compiler gprolog-doc - documentation for the GNU Prolog compiler Changes: gprolog (1.2.18-16) unstable; urgency=low . * touch all *.wam files to ensure buildds don't get mixed up about .pl and .wam having similar modification times. Was having trouble with just about all of them. Files: 95c69817648daedff928332fd6c47ae9 808 devel optional gprolog_1.2.18-16.dsc 0cc91cd6d50e6e8735f7737f423a1f5a 80301 devel optional gprolog_1.2.18-16.diff.gz 8db4f3b3b132aeacd1d5a5fbf4a7 1043718 doc optional gprolog-doc_1.2.18-16_all.deb a01e05c0578825f1ff6e94aacf3fa20f 1240172 devel optional gprolog_1.2.18-16_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFDZyaezoTo55Wk8dYRAoLsAJ9PhhyLKwCLcq5x3rU8sPJsYF0l/QCffqxQ CZ2Jeg+o8VHqNAWBPxzTEhM= =eLad -END PGP SIGNATURE- Accepted: gprolog-doc_1.2.18-16_all.deb to pool/main/g/gprolog/gprolog-doc_1.2.18-16_all.deb gprolog_1.2.18-16.diff.gz to pool/main/g/gprolog/gprolog_1.2.18-16.diff.gz gprolog_1.2.18-16.dsc to pool/main/g/gprolog/gprolog_1.2.18-16.dsc gprolog_1.2.18-16_i386.deb to pool/main/g/gprolog/gprolog_1.2.18-16_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted xscreensaver 4.23-2 (source i386 sparc alpha)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Sun, 30 Oct 2005 14:43:43 +0100 Source: xscreensaver Binary: xscreensaver xscreensaver-gl Architecture: source i386 alpha sparc Version: 4.23-2 Distribution: unstable Urgency: low Maintainer: Ralf Hildebrandt [EMAIL PROTECTED] Changed-By: Ralf Hildebrandt [EMAIL PROTECTED] Description: xscreensaver - Automatic screensaver for X xscreensaver-gl - GL(Mesa) screen hacks for xscreensaver Closes: 331248 334193 335589 336432 Changes: xscreensaver (4.23-2) unstable; urgency=low . * Apply NMU patch (why was there an NMU? Hello? Talk to me before doing an NMU!) (Closes: #334193) * Fix typo in tangram man page (Closes: #336432) * Found out that the upstream already applied the grayscale option patch to bubbles (Closes: #331248) * Suggest xfishtank (Closes: #335589) Files: 748c47973f4c66b297c027c405542ad5 872 x11 optional xscreensaver_4.23-2.dsc 0048e71a65dec0e3cdd3d481c44b30cd 109449 x11 optional xscreensaver_4.23-2.diff.gz 4d35e620b7dfefe398a0fd6a2582efdd 3774572 x11 optional xscreensaver_4.23-2_i386.deb eabc7ff6a2a9f7de4ee816bf45ad6b91 3339396 x11 optional xscreensaver-gl_4.23-2_i386.deb c4bfca516a7b31cfd529e8ea80bb0cac 3985952 x11 optional xscreensaver_4.23-2_sparc.deb a80bbc174ee6c01c2f581a3c02e6ebd1 3449254 x11 optional xscreensaver-gl_4.23-2_sparc.deb 82879c3a5e448221af9bfac9671ae4f2 4855936 x11 optional xscreensaver_4.23-2_alpha.deb 98bcf2bdb2977bb81e2845fdd180abd4 4001636 x11 optional xscreensaver-gl_4.23-2_alpha.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDZyA7ipBneRiAKDwRAuPyAJ4490Wdfj0Nsl2bPxPeGGJMuXnqcwCfcmAM fikLVByHFmHOMQGddPONWlg= =XejU -END PGP SIGNATURE- Accepted: xscreensaver-gl_4.23-2_alpha.deb to pool/main/x/xscreensaver/xscreensaver-gl_4.23-2_alpha.deb xscreensaver-gl_4.23-2_i386.deb to pool/main/x/xscreensaver/xscreensaver-gl_4.23-2_i386.deb xscreensaver-gl_4.23-2_sparc.deb to pool/main/x/xscreensaver/xscreensaver-gl_4.23-2_sparc.deb xscreensaver_4.23-2.diff.gz to pool/main/x/xscreensaver/xscreensaver_4.23-2.diff.gz xscreensaver_4.23-2.dsc to pool/main/x/xscreensaver/xscreensaver_4.23-2.dsc xscreensaver_4.23-2_alpha.deb to pool/main/x/xscreensaver/xscreensaver_4.23-2_alpha.deb xscreensaver_4.23-2_i386.deb to pool/main/x/xscreensaver/xscreensaver_4.23-2_i386.deb xscreensaver_4.23-2_sparc.deb to pool/main/x/xscreensaver/xscreensaver_4.23-2_sparc.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted dpkg-sig 0.12 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Tue, 8 Feb 2005 20:57:21 +0100 Source: dpkg-sig Binary: dpkg-sig Architecture: source all Version: 0.12 Distribution: unstable Urgency: low Maintainer: Andreas Barth [EMAIL PROTECTED] Changed-By: Marc 'HE' Brockschmidt [EMAIL PROTECTED] Description: dpkg-sig - create and verify signatures on .deb-files Closes: 280559 308049 331122 331123 Changes: dpkg-sig (0.12) unstable; urgency=low . * HE - dpkg-sig: + [1-9A-F] describes possible hex digits not as well as [0-9A-F] (Yes, i'm a brainless idiot *sigh*). This should fix the Signer field for people using a 0x\S+0\S+ key id. + If passphrase caching enabled, we now check the passphrase at the beginning (and prompt again if something isn't ok) + Properly quote the $key and $maintainer arguments to gpg. (Closes: #308049) + Let ssh choose the username for a host if it wasn't specified in the URL, this allows the ssh config to do it's job. Thanks for the report, Marc. (Closes: #331122) + Handle ssh errors a *wee* *little* bit better. Almost no improvement, but enough to thank Marc for the report. (Closes: #331123) + Add missing chomps all over the place. + Replace '*changes' in a exec(grep) because that's crap and we know it (the .changes, not the crap). + Use another exit code when trying to verify and finding a bad signature. BAD SIG! GO TO YOUR ROOM! (Closes: #280559) + Check if an unknown key was used to create a signature when verifying a .deb. Output UNKNOWNSIG for those and exit with exitcode 3. + Don't use /usr/bin/perl -W, but /usr/bin/perl -w, which doesn't output stupid warnings. + die gracefully if a file couldn't be found (and don't end the show with a exit 0). Files: 140ad3353809cacc702ad0c45b1815e0 561 devel optional dpkg-sig_0.12.dsc 662e9f37c70c9c43df4342499b6ce39b 27441 devel optional dpkg-sig_0.12.tar.gz ca3a0ef14bd230fe8173c34ef9d1bb1b 37572 devel optional dpkg-sig_0.12_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iEYEARECAAYFAkNnLhwACgkQmO5zOp3h7rFpSQCffKqnkmIErvAo5EUjv0Rykcj6 7VUAoIrUSdrW7zLqtxVvd3XFx4JdsrOh =+Odj -END PGP SIGNATURE- Accepted: dpkg-sig_0.12.dsc to pool/main/d/dpkg-sig/dpkg-sig_0.12.dsc dpkg-sig_0.12.tar.gz to pool/main/d/dpkg-sig/dpkg-sig_0.12.tar.gz dpkg-sig_0.12_all.deb to pool/main/d/dpkg-sig/dpkg-sig_0.12_all.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted easyh10 1.2-1 (source i386 sparc alpha)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Mon, 31 Oct 2005 14:23:57 -0500 Source: easyh10 Binary: easyh10 Architecture: source i386 alpha sparc Version: 1.2-1 Distribution: unstable Urgency: low Maintainer: Benjamin Seidenberg [EMAIL PROTECTED] Changed-By: Benjamin Seidenberg [EMAIL PROTECTED] Description: easyh10- Utility to manage the iRiver H10 music player Changes: easyh10 (1.2-1) unstable; urgency=low . * New upstream release * EasyH10 now oficially supports H10 5GB/6GB UMS 2.51 and H10 5GB/6GB/20GB MTP 2.51 firmware. * Added TCMP (compilation flag) handling for ID3v2 tags. The TCMP field is mainly generated by iTunes to indicate that an MP3 file is a part of an omnibus album. EasyH10 automatically sets Various artists as an artist name and ARTIST - TITLE as a track-title name for MP3 files with TCMP field embedded. Files: 8d47449d2464577838a726de6acdcb5d 606 sound extra easyh10_1.2-1.dsc c258acaac0b96b684e6528e5eeaf300d 404311 sound extra easyh10_1.2.orig.tar.gz 8248be09cff3fbd66afa918894f0d17d 3568 sound extra easyh10_1.2-1.diff.gz 8fef5a94d0974c250986475bbb2bc735 50028 sound extra easyh10_1.2-1_i386.deb e16c8b66e58c868b871c9d164dac75f5 49352 sound extra easyh10_1.2-1_sparc.deb 1e497fbd6d42cc2395153bcd316b3ad2 60150 sound extra easyh10_1.2-1_alpha.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDZzVoipBneRiAKDwRAuOPAJ9itNYRSi8osDaToyx9LZnZxX4RAQCgqWqS IdpeaFSWaswIVqbmeIhqBNg= =+hn/ -END PGP SIGNATURE- Accepted: easyh10_1.2-1.diff.gz to pool/main/e/easyh10/easyh10_1.2-1.diff.gz easyh10_1.2-1.dsc to pool/main/e/easyh10/easyh10_1.2-1.dsc easyh10_1.2-1_alpha.deb to pool/main/e/easyh10/easyh10_1.2-1_alpha.deb easyh10_1.2-1_i386.deb to pool/main/e/easyh10/easyh10_1.2-1_i386.deb easyh10_1.2-1_sparc.deb to pool/main/e/easyh10/easyh10_1.2-1_sparc.deb easyh10_1.2.orig.tar.gz to pool/main/e/easyh10/easyh10_1.2.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted fprobe 1.1-4 (source i386 all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Thu, 13 Oct 2005 19:27:42 +0300 Source: fprobe Binary: fprobe fprobe-ng Architecture: source i386 all Version: 1.1-4 Distribution: unstable Urgency: low Maintainer: Radu Spineanu [EMAIL PROTECTED] Changed-By: Radu Spineanu [EMAIL PROTECTED] Description: fprobe - export captured traffic to remote NetFlow Collector fprobe-ng - export captured traffic to remote NetFlow Collector (meta) Closes: 322869 331475 Changes: fprobe (1.1-4) unstable; urgency=low . * Replace the old fprobe package with the fprobe-ng version (closes: #322869) * Added a fprobe-ng meta package for the fprobe-ng - fprobe transition * Added a note in README.Debian about this change * Updated FSF address in the copyright file * Added Swedish debconf translation (closes: #331475) Thanks to Daniel Nylander [EMAIL PROTECTED] Files: 1e855f670dfbdb1fd3a23fdead022133 601 net optional fprobe_1.1-4.dsc 3fa916231fd303f43813251dc16ec51d 124970 net optional fprobe_1.1.orig.tar.gz 7018a0d530166ee705739b3cdbe7fa7d 4545 net optional fprobe_1.1-4.diff.gz 6d31583d31f3324fe375121f226235b6 8256 net optional fprobe-ng_1.1-4_all.deb 3b5c1e84ac9c72f948ce89c20ca3dc4d 27302 net optional fprobe_1.1-4_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDZk9cJkMZOMmr+9MRAvnzAJ9odJkYq5j6q9gkP5LOOQbWqSmNZACgnPyE Tdwh43RB+VsqocANvp8xn6U= =SUd3 -END PGP SIGNATURE- Accepted: fprobe-ng_1.1-4_all.deb to pool/main/f/fprobe/fprobe-ng_1.1-4_all.deb fprobe_1.1-4.diff.gz to pool/main/f/fprobe/fprobe_1.1-4.diff.gz fprobe_1.1-4.dsc to pool/main/f/fprobe/fprobe_1.1-4.dsc fprobe_1.1-4_i386.deb to pool/main/f/fprobe/fprobe_1.1-4_i386.deb fprobe_1.1.orig.tar.gz to pool/main/f/fprobe/fprobe_1.1.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted crosshurd 1.7.22 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Tue, 1 Nov 2005 00:21:11 +0100 Source: crosshurd Binary: crosshurd Architecture: source all Version: 1.7.22 Distribution: unstable Urgency: low Maintainer: Jeff Bailey [EMAIL PROTECTED] Changed-By: Michael Banck [EMAIL PROTECTED] Description: crosshurd - Install a Debian system Closes: 331219 Changes: crosshurd (1.7.22) unstable; urgency=low . * package/kfreebsd-gnu: Renamed kfreebsd-image-5.3-1 to kreebsd-image-5-486, by Robert Millan. (Closes: #331219) Files: 8bed20a2af67947830650720f6312b49 568 misc extra crosshurd_1.7.22.dsc f35cef4c31b930f86edab154a50522f4 18761 misc extra crosshurd_1.7.22.tar.gz 45cd7158a1c185e54d7f8a6035023aa6 19642 misc extra crosshurd_1.7.22_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFDZz3SmHaJYZ7RAb8RAkNfAKDDA1nTrBYdBBKfiw5MAwTKXlqxGQCghXQj CHwWYPaAof1fLd8p7gcaolI= =U/kN -END PGP SIGNATURE- Accepted: crosshurd_1.7.22.dsc to pool/main/c/crosshurd/crosshurd_1.7.22.dsc crosshurd_1.7.22.tar.gz to pool/main/c/crosshurd/crosshurd_1.7.22.tar.gz crosshurd_1.7.22_all.deb to pool/main/c/crosshurd/crosshurd_1.7.22_all.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted openclipart 0.18+dfsg-1 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Tue, 1 Nov 2005 02:16:07 +0100 Source: openclipart Binary: openclipart-svg openclipart-openoffice.org openclipart-png openclipart Architecture: source all Version: 0.18+dfsg-1 Distribution: unstable Urgency: low Maintainer: Aurelien Jarno [EMAIL PROTECTED] Changed-By: Aurelien Jarno [EMAIL PROTECTED] Description: openclipart - Open Clip Art Library openclipart-openoffice.org - clip art for OpenOffice.org gallery openclipart-png - clip art in PNG format openclipart-svg - clip art in SVG format Changes: openclipart (0.18+dfsg-1) unstable; urgency=low . [ Aurelien Jarno ] * New upstream version. * Lot of changes in the build process. * Seems that rsvg doesn't like some files, process them with inkscape. . [ Rene Engelhard ] * build openclipart-openoffice.org dynamically using gengal instead of shippig manually pre-built files and also let the numbers only start at 70 to avoid collisions with OOo2. Build-Depend on openoffice.org-dev (= 2.0.0) and xvfb (gengal needs X...). * add myself to Uploaders: Files: 8395815ee3d89c94674bc8a00e5ee685 775 graphics extra openclipart_0.18+dfsg-1.dsc a577897f665ed62f095535676f2a2381 89689027 graphics extra openclipart_0.18+dfsg.orig.tar.gz 66e4e94098973d9fed1cd0672733b7bf 30556 graphics extra openclipart_0.18+dfsg-1.diff.gz 27f686e207054911a57695b1d67eb95e 3582 graphics extra openclipart_0.18+dfsg-1_all.deb 08bd3a9e4542f6cf0910bbe2f386418c 39836098 graphics extra openclipart-svg_0.18+dfsg-1_all.deb 3a8ede0d2f968c1e0f894ea48799e537 158534394 graphics extra openclipart-png_0.18+dfsg-1_all.deb d2c76f6045be6eb5fb6e0fd33a5ba789 9434290 graphics extra openclipart-openoffice.org_0.18+dfsg-1_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDZzW9w3ao2vG823MRAowwAJ4t1x4cW0m3pvsRUXrVEwl/LOsqfgCffZ7U qIyHHvwe6B5Vdf5Fjdf7xvI= =rxt5 -END PGP SIGNATURE- Accepted: openclipart-openoffice.org_0.18+dfsg-1_all.deb to pool/main/o/openclipart/openclipart-openoffice.org_0.18+dfsg-1_all.deb openclipart-png_0.18+dfsg-1_all.deb to pool/main/o/openclipart/openclipart-png_0.18+dfsg-1_all.deb openclipart-svg_0.18+dfsg-1_all.deb to pool/main/o/openclipart/openclipart-svg_0.18+dfsg-1_all.deb openclipart_0.18+dfsg-1.diff.gz to pool/main/o/openclipart/openclipart_0.18+dfsg-1.diff.gz openclipart_0.18+dfsg-1.dsc to pool/main/o/openclipart/openclipart_0.18+dfsg-1.dsc openclipart_0.18+dfsg-1_all.deb to pool/main/o/openclipart/openclipart_0.18+dfsg-1_all.deb openclipart_0.18+dfsg.orig.tar.gz to pool/main/o/openclipart/openclipart_0.18+dfsg.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted mpfi 1.3.3-3 (source powerpc)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Tue, 1 Nov 2005 11:13:48 +0100 Source: mpfi Binary: libmpfi-dev Architecture: source powerpc Version: 1.3.3-3 Distribution: unstable Urgency: low Maintainer: Laurent Fousse [EMAIL PROTECTED] Changed-By: Laurent Fousse [EMAIL PROTECTED] Description: libmpfi-dev - multiple precision floating-point interval computation library Closes: 336703 Changes: mpfi (1.3.3-3) unstable; urgency=low . * Apply mpfr-2.2.0 compatibility patch supplied by Patrick Pelissier (closes: #336703). Files: aca51d366dd4d09746d3727e6b98c711 635 math optional mpfi_1.3.3-3.dsc 2a814bcfd20cab541a39c295d7e13258 32374 math optional mpfi_1.3.3-3.diff.gz c67e3182bd0ade71d8adef3df6e0b606 40370 libdevel optional libmpfi-dev_1.3.3-3_powerpc.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDZ0DSRoAVF6FpbSsRArsgAJ9abKVISHnwNnN6SK8q8CYQqE0lAACgjdDO ztpt/s1y7TOt1mqA7pFRbjQ= =UKsM -END PGP SIGNATURE- Accepted: libmpfi-dev_1.3.3-3_powerpc.deb to pool/main/m/mpfi/libmpfi-dev_1.3.3-3_powerpc.deb mpfi_1.3.3-3.diff.gz to pool/main/m/mpfi/mpfi_1.3.3-3.diff.gz mpfi_1.3.3-3.dsc to pool/main/m/mpfi/mpfi_1.3.3-3.dsc -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted beast 0.6.6-1 (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Tue, 1 Nov 2005 00:39:52 +0100 Source: beast Binary: beast Architecture: source i386 Version: 0.6.6-1 Distribution: unstable Urgency: low Maintainer: Sam Hocevar (Debian packages) [EMAIL PROTECTED] Changed-By: Sam Hocevar (Debian packages) [EMAIL PROTECTED] Description: beast - music synthesis and composition framework Closes: 292971 297275 299413 307254 314147 Changes: beast (0.6.6-1) unstable; urgency=low . * New upstream release (Closes: #307254). This version fixes an old FTBFS (Closes: #292971) and uses tput in the configure script instead of an ncurses program that mangled the terminal (Closes: #297275). * debian/control: + Set policy to 3.6.2.1. + Build-depend on libxml2-utils (xmllint). + libtool is a lot nicer now; no longer build-conflict on beast. * debian/rules: + Got rid of an old workaround for GCC bug #10681 that was fixed ages ago. + Add an icon to the menu entry (Closes: #299413). * bse/bsesequencer.cc: + Comment out asserts using G_STRUCT_OFFSET. * bse/bsesong.cc: + Declare functions in the main scope. * po/de.po: + Fixed a typo, thanks to Jens Seidel (Closes: #314147). Files: 22195f4e6ddbedd498aacacd4b2933e4 787 gnome extra beast_0.6.6-1.dsc b79337930476c7a19f211b91857c4b4c 6098356 gnome extra beast_0.6.6.orig.tar.gz cdb9d8722e023248c968a2429f7b 14606 gnome extra beast_0.6.6-1.diff.gz fd1095a88bd490730d529e9b446194a4 4195504 gnome extra beast_0.6.6-1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDZ0BVfPP1rylJn2ERAhydAJ9C/eWMrwFgBHNTGJh0yRBprhVxAwCfQ3zs OdWcheIVwj5UIUeWdlPO3Ck= =H5zg -END PGP SIGNATURE- Accepted: beast_0.6.6-1.diff.gz to pool/main/b/beast/beast_0.6.6-1.diff.gz beast_0.6.6-1.dsc to pool/main/b/beast/beast_0.6.6-1.dsc beast_0.6.6-1_i386.deb to pool/main/b/beast/beast_0.6.6-1_i386.deb beast_0.6.6.orig.tar.gz to pool/main/b/beast/beast_0.6.6.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted libxml-libxml-perl 1.58-3 (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Tue, 1 Nov 2005 11:15:43 +0100 Source: libxml-libxml-perl Binary: libxml-libxml-perl Architecture: source i386 Version: 1.58-3 Distribution: unstable Urgency: low Maintainer: Florian Ragwitz [EMAIL PROTECTED] Changed-By: Florian Ragwitz [EMAIL PROTECTED] Description: libxml-libxml-perl - Perl module for using the GNOME libxml2 library Closes: 335843 Changes: libxml-libxml-perl (1.58-3) unstable; urgency=low . * Fixed syntax error in the maintainer scripts (Closes: #335843). Files: 74c3be85ac626eb0cefd5e841cb5d61d 771 perl optional libxml-libxml-perl_1.58-3.dsc 5f1bbf5ae93223133d9b8bf36a02f1db 10096 perl optional libxml-libxml-perl_1.58-3.diff.gz a6c242b2db34fe4396797034d6dc642d 277720 perl optional libxml-libxml-perl_1.58-3_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDZ0Q2dC8qQo5jWl4RAlHHAJ0WiArleNcTt8FzOH5+FuTcNqbAYACeMApI JdkI3Atxsx0YDwJWsaqEnzo= =xKWz -END PGP SIGNATURE- Accepted: libxml-libxml-perl_1.58-3.diff.gz to pool/main/libx/libxml-libxml-perl/libxml-libxml-perl_1.58-3.diff.gz libxml-libxml-perl_1.58-3.dsc to pool/main/libx/libxml-libxml-perl/libxml-libxml-perl_1.58-3.dsc libxml-libxml-perl_1.58-3_i386.deb to pool/main/libx/libxml-libxml-perl/libxml-libxml-perl_1.58-3_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted caudium 2:1.4.7-7 (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Tue, 1 Nov 2005 11:35:36 +0100 Source: caudium Binary: caudium-ultralog caudium-pixsl caudium-perl caudium caudium-dev caudium-modules Architecture: source i386 Version: 2:1.4.7-7 Distribution: unstable Urgency: low Maintainer: Marek Habersack [EMAIL PROTECTED] Changed-By: Marek Habersack [EMAIL PROTECTED] Description: caudium- An extensible WWW server written in Pike caudium-dev - Development files for Caudium caudium-modules - C modules for Caudium caudium-perl - Perl script support for Caudium caudium-pixsl - Pike XSLT module for Caudium caudium-ultralog - Log Parser module for Caudium Closes: 336383 336742 Changes: caudium (2:1.4.7-7) unstable; urgency=low . * Note to self: don't work when half asleep. Thanks Mario for noticing my braindamage :) - fixed the postrm/prerm files. * please remove files created in postinst (Closes: #336383) * please support delayed compressed logs for webalizer (Closes: #336742). Added the 'delaycompress' option to the logrotate config file Files: 2c9ddb7370200ed169628da625e82119 846 web optional caudium_1.4.7-7.dsc bc073305e3aea3aece2a50385b35a4f7 96869 web optional caudium_1.4.7-7.diff.gz 5b036a79d392e518731e47f6d1174d51 4523180 web optional caudium_1.4.7-7_i386.deb 9ea63d436682e1bd1973093e89a4a1f2 57420 web optional caudium-modules_1.4.7-7_i386.deb ea82ac02f473e28de47d96ad39568485 38658 web optional caudium-pixsl_1.4.7-7_i386.deb 3fc8661d7a9358d2beeaafd02fc50da6 73138 web optional caudium-ultralog_1.4.7-7_i386.deb 7d4f4938a3e1d8adec59bf4109a8c042 23100 devel optional caudium-dev_1.4.7-7_i386.deb a29c5acd0674ed35a86ad4e40dc0b1b2 31374 web optional caudium-perl_1.4.7-7_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFDZ0iSq3909GIf5uoRAmD4AJ4kb501+dtTTCjpx5YZ8A0HJrMA+QCdEj7d umIVEWdPwTPTXDn5wRVBJ4s= =ZRc/ -END PGP SIGNATURE- Accepted: caudium-dev_1.4.7-7_i386.deb to pool/main/c/caudium/caudium-dev_1.4.7-7_i386.deb caudium-modules_1.4.7-7_i386.deb to pool/main/c/caudium/caudium-modules_1.4.7-7_i386.deb caudium-perl_1.4.7-7_i386.deb to pool/main/c/caudium/caudium-perl_1.4.7-7_i386.deb caudium-pixsl_1.4.7-7_i386.deb to pool/main/c/caudium/caudium-pixsl_1.4.7-7_i386.deb caudium-ultralog_1.4.7-7_i386.deb to pool/main/c/caudium/caudium-ultralog_1.4.7-7_i386.deb caudium_1.4.7-7.diff.gz to pool/main/c/caudium/caudium_1.4.7-7.diff.gz caudium_1.4.7-7.dsc to pool/main/c/caudium/caudium_1.4.7-7.dsc caudium_1.4.7-7_i386.deb to pool/main/c/caudium/caudium_1.4.7-7_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted gartoon 0.5-2 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Tue, 1 Nov 2005 08:54:55 -0200 Source: gartoon Binary: gnome-icon-theme-gartoon Architecture: source all Version: 0.5-2 Distribution: unstable Urgency: low Maintainer: Otavio Salvador [EMAIL PROTECTED] Changed-By: Otavio Salvador [EMAIL PROTECTED] Description: gnome-icon-theme-gartoon - Gartoon icon theme for GTK+ 2.x Closes: 332662 333421 Changes: gartoon (0.5-2) unstable; urgency=low . * debian/control: - Change our depends field to librsvg2-common. Closes: #333421 - Bump Standards-Version to 3.6.2. No changes was need. * debian/copyright: Update FSF address. * debian/rules: Force 644 mode on all .svg files. Closes: #332662 Files: 97a776adfb90ec238556a80ec0fdfe73 581 gnome optional gartoon_0.5-2.dsc 9e6d1be4f6f25f75c339f009522561ed 2233 gnome optional gartoon_0.5-2.diff.gz a1413ad4c20835e2bb7a8ee50ec18de0 1519046 gnome optional gnome-icon-theme-gartoon_0.5-2_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDZ0zLLqiZQEml+FURAphSAKCPzt884y2nVRXOeKikKOuO+MdMewCff4DF 33pPQglixE/FVpeCdM4t1Vk= =K4y7 -END PGP SIGNATURE- Accepted: gartoon_0.5-2.diff.gz to pool/main/g/gartoon/gartoon_0.5-2.diff.gz gartoon_0.5-2.dsc to pool/main/g/gartoon/gartoon_0.5-2.dsc gnome-icon-theme-gartoon_0.5-2_all.deb to pool/main/g/gartoon/gnome-icon-theme-gartoon_0.5-2_all.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted langdrill 0.3-5 (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Mon, 31 Oct 2005 23:50:59 +0100 Source: langdrill Binary: langdrill Architecture: source i386 Version: 0.3-5 Distribution: unstable Urgency: low Maintainer: Sam Hocevar (Debian packages) [EMAIL PROTECTED] Changed-By: Sam Hocevar (Debian packages) [EMAIL PROTECTED] Description: langdrill - language drills to test vocabulary Closes: 310765 Changes: langdrill (0.3-5) unstable; urgency=low . * Rebuild for the C++ transition. * debian/control: + Set policy to 3.6.2.1. + Build-depend on libvdk2-dev (= 2.4.0-3). + Fixed grammar in the long description. * debian/rules: + Use dh_installman instead of dh_installmanpages. * debian/copyright: + Fixed old FSF address. + Added proper copyright holders. * src/main.hh src/config.cc src/config.hh: + Fixed use of deprecated C++ headers. * src/main.cc: + Fixed event handling in the simple quizz panel (Closes: #310765). Files: c344f682be58a995f3567f6836e96f00 628 gnome optional langdrill_0.3-5.dsc c506bb2f9810e794654445864e013150 17072 gnome optional langdrill_0.3-5.diff.gz 7f1ccce43e129480a3a8807c18633bd6 48998 gnome optional langdrill_0.3-5_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDZ05cfPP1rylJn2ERAnzvAJ43ND2xsbQ5dXag4QzIj8NvUF4YpACfRQqp IWfE4RE0kpABT2Vgk3IgQVU= =J5Fk -END PGP SIGNATURE- Accepted: langdrill_0.3-5.diff.gz to pool/main/l/langdrill/langdrill_0.3-5.diff.gz langdrill_0.3-5.dsc to pool/main/l/langdrill/langdrill_0.3-5.dsc langdrill_0.3-5_i386.deb to pool/main/l/langdrill/langdrill_0.3-5_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted glade 2.12.1-2 (source all i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Tue, 1 Nov 2005 11:41:54 +0100 Source: glade Binary: glade-common glade-doc glade-doc-2 glade glade-2 glade-gnome glade-gnome-2 glade-common-2 Architecture: source all i386 Version: 2.12.1-2 Distribution: experimental Urgency: high Maintainer: Gustavo Noronha Silva [EMAIL PROTECTED] Changed-By: Loic Minier [EMAIL PROTECTED] Description: glade - GTK+ 2 User Interface Builder glade-2- Dummy upgrade package for glade glade-common - Common files for GTK+ 2 User Interface Builder glade-common-2 - Dummy upgrade package for glade-common glade-doc - Documentation for GTK+ 2 User Interface Builder glade-doc-2 - Dummy upgrade package for glade-doc glade-gnome - GTK+ 2 User Interface Builder (with GNOME 2 support) glade-gnome-2 - Dummy upgrade package for glade-gnome Closes: 334194 Changes: glade (2.12.1-2) experimental; urgency=high . * Bump libgtk2.0-dev build-dep to = 2.8.0. (Closes: #334194) [debian/control, debian/control.in] Files: 3aaf85d9db8bdf801b3316136cf41f3a 2012 gnome optional glade_2.12.1-2.dsc dca2eff0156fa5e7c417d01c70de2af5 17532 gnome optional glade_2.12.1-2.diff.gz afdea95d8b432da5ad59b4641b566c3c 149694 doc optional glade-doc_2.12.1-2_all.deb cbd2827c56fdc372d82543280f4138f7 113666 devel optional glade-common_2.12.1-2_all.deb 6d6a21aabea3da7c106c6d9095f12a54 77602 devel extra glade-2_2.12.1-2_all.deb 7e283f65012dc12b77cc3197d1cf115e 77614 gnome optional glade-gnome-2_2.12.1-2_all.deb d97385392c95baa895109f94ab6dff57 77612 doc optional glade-doc-2_2.12.1-2_all.deb 4248dadd47d59e3a83732ba03bb2f280 77618 devel optional glade-common-2_2.12.1-2_all.deb 19216c4915311d6bd8b46c86a2065c20 1556948 devel extra glade_2.12.1-2_i386.deb 5b30e2ee585232c584a5cd87e023b1e3 1627122 gnome optional glade-gnome_2.12.1-2_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDZ00Q4VUX8isJIMARAm6uAJwLU1weSRYJxkpAroG2ZkN7KnuIQwCfdKi3 MKxOXIPZtEwX0xaqZBr6Kew= =JNR2 -END PGP SIGNATURE- Accepted: glade-2_2.12.1-2_all.deb to pool/main/g/glade/glade-2_2.12.1-2_all.deb glade-common-2_2.12.1-2_all.deb to pool/main/g/glade/glade-common-2_2.12.1-2_all.deb glade-common_2.12.1-2_all.deb to pool/main/g/glade/glade-common_2.12.1-2_all.deb glade-doc-2_2.12.1-2_all.deb to pool/main/g/glade/glade-doc-2_2.12.1-2_all.deb glade-doc_2.12.1-2_all.deb to pool/main/g/glade/glade-doc_2.12.1-2_all.deb glade-gnome-2_2.12.1-2_all.deb to pool/main/g/glade/glade-gnome-2_2.12.1-2_all.deb glade-gnome_2.12.1-2_i386.deb to pool/main/g/glade/glade-gnome_2.12.1-2_i386.deb glade_2.12.1-2.diff.gz to pool/main/g/glade/glade_2.12.1-2.diff.gz glade_2.12.1-2.dsc to pool/main/g/glade/glade_2.12.1-2.dsc glade_2.12.1-2_i386.deb to pool/main/g/glade/glade_2.12.1-2_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted libgtop2 2.12.0-2 (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Tue, 1 Nov 2005 12:44:28 +0100 Source: libgtop2 Binary: libgtop2-5 libgtop2-dev Architecture: source i386 Version: 2.12.0-2 Distribution: experimental Urgency: high Maintainer: Sebastien Bacher [EMAIL PROTECTED] Changed-By: Loic Minier [EMAIL PROTECTED] Description: libgtop2-5 - Libraries for gtop system monitoring library (part of Gnome 2) libgtop2-dev - Dev libraries for gtop system monitoring library (part of Gnome 2 Closes: 336736 Changes: libgtop2 (2.12.0-2) experimental; urgency=high . * Bump shlibs to = 2.12.0 since the #define'd functions of the API are now real symbols. (Closes: #336736) [debian/rules] * Add CDBS' utils. [debian/rules] * Fix license. [debian/copyright] * Bump up Standards-Version to 3.6.2. [debian/control, debian/control.in] Files: 1b10b5976dd6d6b64302541c9d41df21 1654 libs optional libgtop2_2.12.0-2.dsc 13681fc3bbc2c110fd093982300e4e75 5684 libs optional libgtop2_2.12.0-2.diff.gz af884f4f1043674341d4557f0c6a847f 115894 libs optional libgtop2-5_2.12.0-2_i386.deb 7fb2c63945516d2c8b04a05f214944bd 96882 libdevel optional libgtop2-dev_2.12.0-2_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDZ1Wd4VUX8isJIMARAhOkAJ40dBHBhqHru4S46vBroM1PJVZAJwCfRYCs a8oZmiNMrnMXb2qvxF4BuWg= =hp+x -END PGP SIGNATURE- Accepted: libgtop2-5_2.12.0-2_i386.deb to pool/main/libg/libgtop2/libgtop2-5_2.12.0-2_i386.deb libgtop2-dev_2.12.0-2_i386.deb to pool/main/libg/libgtop2/libgtop2-dev_2.12.0-2_i386.deb libgtop2_2.12.0-2.diff.gz to pool/main/libg/libgtop2/libgtop2_2.12.0-2.diff.gz libgtop2_2.12.0-2.dsc to pool/main/libg/libgtop2/libgtop2_2.12.0-2.dsc -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted gnome-system-monitor 2.12.1-2 (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Tue, 1 Nov 2005 12:41:42 +0100 Source: gnome-system-monitor Binary: gnome-system-monitor Architecture: source i386 Version: 2.12.1-2 Distribution: experimental Urgency: low Maintainer: Sebastien Bacher [EMAIL PROTECTED] Changed-By: Loic Minier [EMAIL PROTECTED] Description: gnome-system-monitor - Process viewer and system resource monitor for GNOME 2 Closes: 336760 Changes: gnome-system-monitor (2.12.1-2) experimental; urgency=low . * Create patches directory. [debian/patches] * Build with fixed libgtop2 shlibs and build-depend on = 2.12.0-2. (Closes: #336760) [debian/control, debian/control.in] Files: 576c6a08f0f9fc1d5ff468e945f8db01 1893 gnome optional gnome-system-monitor_2.12.1-2.dsc 120d3916bb66fba354db78dc25789cdb 6343 gnome optional gnome-system-monitor_2.12.1-2.diff.gz c1322d3ff80c2d86a357e69c90b063d4 613464 gnome optional gnome-system-monitor_2.12.1-2_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDZ1b34VUX8isJIMARAttsAJ0eCWkz38pSbXZDKNwy3f7azj+qywCeND8m pKaoNc7VMN3zvJwarp7hg+4= =rFW/ -END PGP SIGNATURE- Accepted: gnome-system-monitor_2.12.1-2.diff.gz to pool/main/g/gnome-system-monitor/gnome-system-monitor_2.12.1-2.diff.gz gnome-system-monitor_2.12.1-2.dsc to pool/main/g/gnome-system-monitor/gnome-system-monitor_2.12.1-2.dsc gnome-system-monitor_2.12.1-2_i386.deb to pool/main/g/gnome-system-monitor/gnome-system-monitor_2.12.1-2_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted linux-2.6 2.6.14-2 (source i386 all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Tue, 1 Nov 2005 15:27:40 +0900 Source: linux-2.6 Binary: linux-image-sun3 linux-image-2.6.14-1-em64t-p4-smp linux-image-2.6-powerpc-miboot linux-headers-2.6.14-1-atari linux-image-2.6-footbridge linux-image-2.6.14-1-rpc linux-image-2.6-amd64-generic linux-headers-2.6-64-smp kernel-image-2.6-686-smp linux-image-2.6.14-1-ixp4xx linux-image-2.6.14-1-mvme16x linux-headers-2.6-atari kernel-image-2.6-386 linux-headers-2.6-s390 linux-headers-2.6.14-1-amd64-k8-smp linux-image-mvme16x linux-headers-2.6.14-1-mac linux-image-2.6.14-1-mac linux-image-itanium linux-image-2.6.14-1-686 linux-image-2.6-amd64-k8-smp linux-image-2.6-rpc linux-headers-2.6.14-1-alpha-generic linux-image-2.6.14-1-em64t-p4 linux-image-2.6-s390 linux-image-q40 linux-headers-2.6-sparc64-smp linux-headers-2.6-mvme147 linux-headers-2.6.14-1-itanium linux-headers-2.6.14-1-amd64-generic linux-image-footbridge linux-headers-2.6.14-1-footbridge kernel-image-2.6-itanium-smp linux-headers-2.6.14-1-386 linux-headers-2.6-686-smp linux-image-atari linux-image-2.6-q40 linux-manual-2.6.14 kernel-image-2.6-k7-smp linux-headers-2.6.14-1-64 linux-headers-2.6-powerpc-miboot linux-headers-2.6.14-1-s390x linux-image-s390 linux-headers-2.6.14-1-64-smp linux-headers-2.6.14-1-686 linux-patch-debian-2.6.14 linux-headers-2.6.14-1-q40 linux-image-2.6-itanium linux-image-amd64-k8-smp linux-image-2.6.14-1-bvme6000 linux-headers-2.6.14-1-amd64-k8 linux-image-2.6.14-1-powerpc-smp linux-headers-2.6-amd64-generic linux-headers-2.6.14-1-em64t-p4-smp linux-image-2.6-mckinley-smp linux-image-2.6.14-1-itanium linux-image-2.6.14-1-itanium-smp linux-image-amiga linux-image-2.6-k7 linux-headers-2.6.14-1-k7-smp linux-headers-2.6.14-1-amiga linux-image-mckinley-smp linux-image-em64t-p4-smp linux-image-2.6-powerpc linux-headers-2.6.14-1-itanium-smp linux-headers-2.6-s3c2410 linux-headers-2.6.14-1-sun3 linux-image-2.6-hp linux-image-sparc64-smp linux-image-2.6.14-1-sparc64-smp linux-image-2.6.14-1-64-smp linux-headers-2.6.14-1-mvme16x linux-image-2.6.14-1-amd64-k8-smp kernel-image-2.6-mckinley linux-image-2.6.14-1-amd64-generic linux-image-powerpc-smp linux-headers-2.6-itanium-smp linux-image-2.6.14-1-k7-smp kernel-image-2.6-power3 linux-image-2.6-64-smp kernel-image-2.6-powerpc linux-headers-2.6-32 linux-tree-2.6.14 kernel-image-2.6-generic linux-headers-2.6-mvme16x linux-headers-2.6.14-1-s3c2410 linux-image-2.6-alpha-generic linux-headers-2.6-amd64-k8-smp linux-image-2.6-em64t-p4 linux-headers-2.6.14-1-bvme6000 linux-image-32 linux-headers-2.6.14-1-powerpc-smp linux-headers-2.6-powerpc linux-image-hp linux-headers-2.6-em64t-p4-smp kernel-image-powerpc-smp linux-headers-2.6-sparc64 linux-image-powerpc64 linux-headers-2.6-hp linux-headers-2.6.14 linux-headers-2.6-powerpc64 linux-image-2.6.14-1-mckinley linux-image-2.6.14-1-alpha-smp linux-image-2.6.14-1-footbridge linux-headers-2.6.14-1-alpha-smp linux-image-2.6.14-1-powerpc-miboot linux-headers-2.6-mac linux-headers-2.6-32-smp linux-headers-2.6.14-1 linux-headers-2.6-em64t-p4 linux-image-2.6.14-1-hp linux-headers-2.6-rpc linux-headers-2.6.14-1-mckinley-smp linux-image-2.6.14-1-sun3 linux-image-2.6-mckinley linux-headers-2.6.14-1-sparc64-smp linux-headers-2.6-alpha-generic linux-headers-2.6-bvme6000 kernel-image-2.6-sparc64-smp kernel-image-powerpc linux-image-bvme6000 linux-headers-2.6-alpha-smp linux-headers-2.6.14-1-sparc64 linux-image-2.6.14-1-q40 linux-image-2.6-atari linux-image-64 linux-image-s3c2410 linux-headers-2.6-386 linux-doc-2.6.14 linux-image-2.6.14-1-s390x linux-headers-2.6-sun3 linux-image-2.6.14-1-mvme147 linux-image-2.6.14-1-powerpc64 linux-headers-2.6-mckinley-smp kernel-image-2.6-power4-smp linux-image-k7-smp linux-image-386 linux-image-2.6.14-1-386 linux-source-2.6.14 kernel-image-power3-smp linux-headers-2.6.14-1-ixp4xx linux-headers-2.6.14-1-hp linux-image-2.6-bvme6000 linux-image-mckinley linux-headers-2.6.14-1-32 linux-image-itanium-smp linux-headers-2.6.14-1-em64t-p4 linux-image-2.6-sparc64-smp linux-headers-2.6-s390x linux-image-2.6-ixp4xx linux-headers-2.6-q40 linux-image-2.6.14-1-powerpc kernel-image-2.6-k7 linux-image-ixp4xx linux-image-rpc linux-image-2.6-mac linux-image-2.6.14-1-s3c2410 linux-headers-2.6-64 linux-headers-2.6.14-1-k7 kernel-image-2.6-power3-smp linux-image-2.6-s390x kernel-image-2.6-smp linux-headers-2.6.14-1-686-smp linux-image-alpha-smp linux-image-2.6-amd64-k8 linux-image-2.6.14-1-32 linux-image-2.6.14-1-s390 linux-headers-2.6.14-1-powerpc64 linux-image-2.6.14-1-alpha-generic linux-headers-2.6-footbridge linux-headers-2.6.14-1-mckinley linux-image-2.6-sparc64 linux-headers-2.6.14-1-powerpc linux-image-amd64-k8 kernel-image-power4 linux-image-2.6.14-1-atari linux-image-2.6-s3c2410 linux-image-2.6.14-1-32-smp linux-image-2.6.14-1-sparc64 linux-image-2.6.14-1-mckinley-smp linux-headers-2.6-k7-smp linux-headers-2.6.14-1-mvme147
Accepted igal 1.4-14 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Tue, 1 Nov 2005 22:28:13 +1000 Source: igal Binary: igal Architecture: source all Version: 1.4-14 Distribution: unstable Urgency: low Maintainer: Alexander Zangerl [EMAIL PROTECTED] Changed-By: Alexander Zangerl [EMAIL PROTECTED] Description: igal - online image gallery generator Closes: 335529 335857 335860 Changes: igal (1.4-14) unstable; urgency=low . * applied patch to make thumbnail generation look at picture mtime (closes: #335860) * applied patch to fix url encoding of file names (closes: #335857) * applied patch to add -U option (filenames as thumbnail captions) (closes: #335529) * lifted standards version Files: af10173b6f1c96ec5f80d21140c0cc67 551 web optional igal_1.4-14.dsc 17e1cfb41270705565f12540771a3bd0 28908 web optional igal_1.4-14.diff.gz eceadb18943ebbfe983ed6ebec51e27c 24710 web optional igal_1.4-14_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFDZ1+Npy/2bEK9ZF0RAuQaAJ9dWhJDu0UpHOyWVqk3O/q25bwryACfXK22 oK0GE1EgexOpC0unOpbuR/0= =9KVC -END PGP SIGNATURE- Accepted: igal_1.4-14.diff.gz to pool/main/i/igal/igal_1.4-14.diff.gz igal_1.4-14.dsc to pool/main/i/igal/igal_1.4-14.dsc igal_1.4-14_all.deb to pool/main/i/igal/igal_1.4-14_all.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted dctc 0.85.9-3 (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Tue, 1 Nov 2005 14:35:16 +0100 Source: dctc Binary: dctc Architecture: source i386 Version: 0.85.9-3 Distribution: unstable Urgency: medium Maintainer: Debian QA Group [EMAIL PROTECTED] Changed-By: Matej Vela [EMAIL PROTECTED] Description: dctc - Direct Connect Text Client Closes: 335435 Changes: dctc (0.85.9-3) unstable; urgency=medium . * QA upload. * src/main.c, src/main_master.c: Use hardcoded value for SEMVMX since linux/sem.h may not be available, and sysconf(_SC_SEM_VALUE_MAX) is currently unimplemented. Closes: #335435. * Change section to net in accordance with the override file. * Fix typos in the description. * configure..: Remove cruft left over in the Debian diff. * debian/rules: - Upstream seems to have accidentally moved the Documentation directory to Documentation/Documentation; adjust install rules. - Add support for DEB_BUILD_OPTIONS=noopt. - Remove support for DEB_BUILD_OPTIONS=debug. - Let dh_strip handle DEB_BUILD_OPTIONS=nostrip. * debian/copyright: Update upstream URL and author's e-mail. * debian/watch: Add. Files: 5069b86d24addbdda3510bbe5a31f261 634 net optional dctc_0.85.9-3.dsc 45931e4029919fb66fea4c1ced80bf9c 290755 net optional dctc_0.85.9-3.diff.gz 9c0029a6b79660a1d1153637a50f5ffe 288262 net optional dctc_0.85.9-3_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDZ29GxBYivKllgY8RAnwmAKDQDaqjo6WPtugV6FldQQUtFRYYGwCeN+RR dGlzfFIIUqVVqOdKbYRQ/To= =hR+d -END PGP SIGNATURE- Accepted: dctc_0.85.9-3.diff.gz to pool/main/d/dctc/dctc_0.85.9-3.diff.gz dctc_0.85.9-3.dsc to pool/main/d/dctc/dctc_0.85.9-3.dsc dctc_0.85.9-3_i386.deb to pool/main/d/dctc/dctc_0.85.9-3_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted acidlab 0.9.6b20-13 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Sun, 30 Oct 2005 22:05:35 +0100 Source: acidlab Binary: acidlab-doc acidlab-pgsql acidlab acidlab-mysql Architecture: source all Version: 0.9.6b20-13 Distribution: unstable Urgency: high Maintainer: Jeremy T. Bouse [EMAIL PROTECTED] Changed-By: Javier Fernandez-Sanguino Pen~a [EMAIL PROTECTED] Description: acidlab- Analysis Console for Intrusion Databases acidlab-doc - Analysis Console for Intrusion Databases (documentation) acidlab-mysql - Analysis Console for Intrusion Databases for MySQL acidlab-pgsql - Analysis Console for Intrusion Databases for Postgres Closes: 155212 247730 270171 303217 307712 314566 315135 331732 Changes: acidlab (0.9.6b20-13) unstable; urgency=high . * Patch [013] SECURITY fix: - Add proper filtering in all ImportHTTP variables using either the new functions to check for numeric/alphanumeric chars or the filterSql() function to prevent SQL injection attacks. This patch fixes CVE-2005-3325 but also other attack vectors not mentioned in the initial advisory (http://www.frsirt.com/english/advisories/2005/2188) * Patch [014] Updated dates of php selections up to 2007 * Changed patch [010]: fix locations of Nessus * New patch [015]: fix location of Snort database, provided alternative Ports lookup and added alternative locations for DNS queries (Closes: #315135) * Fixed FSF address in debian/copyright * Patch [016]: Allow graphic data to be represented until 2007. This patch together with patch [014] means that acid's last date is 2007 which should be enough since we are going to replace it with BASE in the short term (Closes: #314566, #307712, #303217, #270171) * Document the changes that need to be done in order to extend the available year options (Closes: #247730) * Added a debian/TODO to describe how to fix the issue with new years with a simple for each loop. * Acidlab now depends on | debconf-2.0 as requested by Joey Hess, I changed debian/packages instead of debian/control this time (Closes: #331732) * To reduce the risk of possible vulnerabilities in the code, made the default apache.conf allow access only from localhost and document this in the README file * Document the fact that this version is actually 0.9.6b20+patches from the latest upstream release 0.9.6b23 and that the later will never be released. (Closes: #155212) * Added the upstream homepage to all package descriptions. Files: 738b1a585919b2b924e24fbb34ce3be7 840 web extra acidlab_0.9.6b20-13.dsc 7b39c7253ad82010d391af41e4c97d14 354649 web extra acidlab_0.9.6b20-13.diff.gz 379034fb2cff2fdfa89544ed970337ed 5212 web extra acidlab-mysql_0.9.6b20-13_all.deb 9ef04ab7465ea79030e1a0730162dd8c 5212 web extra acidlab-pgsql_0.9.6b20-13_all.deb 70d81053834bee5af9efe9a47a2b2b69 276742 web extra acidlab-doc_0.9.6b20-13_all.deb 2a3bc0f45d4b6f7afbdc760715676563 663152 web extra acidlab_0.9.6b20-13_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iQCVAwUBQ2dxS/tEPvakNq0lAQI/TAQAqHql26lFMOqn1tMtptBx3NB8fO/UwSSq Mvr/eQHkw6b1g3ep3P5EwMh7pPzVHphUVsV8HFUXCRcYWllxYS99bir7mNWrJmvh eoBowIV/siRUUdZrNrrDQLbDW7ACgW05yE9yBBbHNw4cp9hVTbBVE1GWZv6BK6wJ kn3TycSBiQc= =fuif -END PGP SIGNATURE- Accepted: acidlab-doc_0.9.6b20-13_all.deb to pool/main/a/acidlab/acidlab-doc_0.9.6b20-13_all.deb acidlab-mysql_0.9.6b20-13_all.deb to pool/main/a/acidlab/acidlab-mysql_0.9.6b20-13_all.deb acidlab-pgsql_0.9.6b20-13_all.deb to pool/main/a/acidlab/acidlab-pgsql_0.9.6b20-13_all.deb acidlab_0.9.6b20-13.diff.gz to pool/main/a/acidlab/acidlab_0.9.6b20-13.diff.gz acidlab_0.9.6b20-13.dsc to pool/main/a/acidlab/acidlab_0.9.6b20-13.dsc acidlab_0.9.6b20-13_all.deb to pool/main/a/acidlab/acidlab_0.9.6b20-13_all.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted openssl 0.9.8a-3 (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Tue, 1 Nov 2005 14:56:40 +0100 Source: openssl Binary: libssl-dev openssl libssl0.9.8-dbg libcrypto0.9.8-udeb libssl0.9.8 Architecture: source i386 Version: 0.9.8a-3 Distribution: unstable Urgency: high Maintainer: Debian OpenSSL Team [EMAIL PROTECTED] Changed-By: Kurt Roeckx [EMAIL PROTECTED] Description: libcrypto0.9.8-udeb - crypto shared library - udeb (udeb) libssl-dev - SSL development libraries, header files and documentation libssl0.9.8 - SSL shared libraries libssl0.9.8-dbg - Symbol tables for libssl and libcrypt openssl- Secure Socket Layer (SSL) binary and related cryptographic tools Closes: 334180 335271 336140 Changes: openssl (0.9.8a-3) unstable; urgency=high . * Link to libz instead of dynamicly loading it. It gets loaded at the moment the library is initialised, so there is no point in not linking to it. It's now failing in some cases since it's not opened by it's soname, but by the symlink to it. This should hopefully solve most of the bugs people have reported since the move to libssl0.9.8. (Closes: #334180, #336140, #335271) * Urgency set to high because it fixes a grave bug affecting testing. Files: fd02eb650aba1fdd5f7cfb573e4afb0a 792 utils optional openssl_0.9.8a-3.dsc fcd0ab21eaad164a061b7eae9a037ca4 30440 utils optional openssl_0.9.8a-3.diff.gz f289b9be7f2ff250946b42f5d41beadc 976886 utils optional openssl_0.9.8a-3_i386.deb f9e97c84785c339238de02a508cbad44 2644302 libs important libssl0.9.8_0.9.8a-3_i386.deb b36ceec7a5a3d343fffc71a7b34308c3 508484 debian-installer optional libcrypto0.9.8-udeb_0.9.8a-3_i386.udeb 453a52b0e5dba787a492cd0b44550216 2835674 libdevel optional libssl-dev_0.9.8a-3_i386.deb 9aaeea23f0d287fd48db6e5567f3ef81 5149816 libdevel extra libssl0.9.8-dbg_0.9.8a-3_i386.deb Package-Type: udeb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFDZ3pcQdwckHJElwsRAm38AKCkoMk4klYQCeQqSiRboKdX16REbACfXw9M HPuZQZWFcg5x8foFfvxPtss= =4ApC -END PGP SIGNATURE- Accepted: libcrypto0.9.8-udeb_0.9.8a-3_i386.udeb to pool/main/o/openssl/libcrypto0.9.8-udeb_0.9.8a-3_i386.udeb libssl-dev_0.9.8a-3_i386.deb to pool/main/o/openssl/libssl-dev_0.9.8a-3_i386.deb libssl0.9.8-dbg_0.9.8a-3_i386.deb to pool/main/o/openssl/libssl0.9.8-dbg_0.9.8a-3_i386.deb libssl0.9.8_0.9.8a-3_i386.deb to pool/main/o/openssl/libssl0.9.8_0.9.8a-3_i386.deb openssl_0.9.8a-3.diff.gz to pool/main/o/openssl/openssl_0.9.8a-3.diff.gz openssl_0.9.8a-3.dsc to pool/main/o/openssl/openssl_0.9.8a-3.dsc openssl_0.9.8a-3_i386.deb to pool/main/o/openssl/openssl_0.9.8a-3_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted xmms-crossfade 0.3.8-1 (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Tue, 1 Nov 2005 15:14:44 +0100 Source: xmms-crossfade Binary: xmms-crossfade Architecture: source i386 Version: 0.3.8-1 Distribution: unstable Urgency: low Maintainer: Florian Ernst [EMAIL PROTECTED] Changed-By: Florian Ernst [EMAIL PROTECTED] Description: xmms-crossfade - XMMS Plugin for Crossfading / Continuous Output Closes: 302431 328270 328272 335091 Changes: xmms-crossfade (0.3.8-1) unstable; urgency=low . * New upstream release (Closes: #328272) + was re-libtoolized, thus reducing the diff.gz size (Closes: #328270) + uses libsamplerate * New maintainer (Closes: #335091) + pick up old rules, dropping cdbs as I personally don't like it + dropy some unneeded files from the diff.gz + simplify Build-Dependencies, also adding libsamplerate0-dev + extend long description + update debian/copyright to reflect changes * Standards-Version 3.6.2 * Acknowledge previous NMU via -v0.3.5-1 . xmms-crossfade (0.3.5-1.1) unstable; urgency=low . * Non-maintainer upload as requested by maintainer. * FTBFS (amd64/gcc-4.0): static declaration of 'monitor_win' follows non-static declaration, fixed by applying the patch provided by Andreas Jochens (Closes: #302431) Files: 34054c065505da295c672482f512da1b 635 sound optional xmms-crossfade_0.3.8-1.dsc fbfff1bff29118309b0a02c713b13d50 435761 sound optional xmms-crossfade_0.3.8.orig.tar.gz 0f45862a4c5c21a8feadb32cabfb18a8 4255 sound optional xmms-crossfade_0.3.8-1.diff.gz 7388f832ec8c6e681c049d014f961d2c 91874 sound optional xmms-crossfade_0.3.8-1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFDZ3uPs3U+TVFLPnwRAuODAJ9TM9Z3A8Nbt+OL0x2dzQy6acEOnQCdEkuI se+zF4ouRgG1GV0x6eu3//U= =50L2 -END PGP SIGNATURE- Accepted: xmms-crossfade_0.3.8-1.diff.gz to pool/main/x/xmms-crossfade/xmms-crossfade_0.3.8-1.diff.gz xmms-crossfade_0.3.8-1.dsc to pool/main/x/xmms-crossfade/xmms-crossfade_0.3.8-1.dsc xmms-crossfade_0.3.8-1_i386.deb to pool/main/x/xmms-crossfade/xmms-crossfade_0.3.8-1_i386.deb xmms-crossfade_0.3.8.orig.tar.gz to pool/main/x/xmms-crossfade/xmms-crossfade_0.3.8.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted sensors-applet 1.5.2-1 (source powerpc)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Sat, 29 Oct 2005 13:09:34 +0100 Source: sensors-applet Binary: sensors-applet Architecture: source powerpc Version: 1.5.2-1 Distribution: unstable Urgency: low Maintainer: [EMAIL PROTECTED] Changed-By: Sam Morris [EMAIL PROTECTED] Description: sensors-applet - Display readings from hardware sensors in your Gnome panel Changes: sensors-applet (1.5.2-1) unstable; urgency=low . * New upstream release * debian/patches/offset_finegrain.diff: merged upstream Files: 0eefa99a2aea17abccc68276325a939f 739 gnome optional sensors-applet_1.5.2-1.dsc 51a98bfae1ff53c6a41465485bd33a6c 153718 gnome optional sensors-applet_1.5.2.orig.tar.gz 9d4a016baf2d179bc9df666a640f7c06 2998 gnome optional sensors-applet_1.5.2-1.diff.gz a20b7a08c5bbad2b0be420535838411a 42072 gnome optional sensors-applet_1.5.2-1_powerpc.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDZ3w8ABzeamt51AERAn5BAKCfiiM0Lf5TH58Indt/ZPHxQ9lNvgCaA68X UvPYceP+uVclu8eqbacW2pk= =COgF -END PGP SIGNATURE- Accepted: sensors-applet_1.5.2-1.diff.gz to pool/main/s/sensors-applet/sensors-applet_1.5.2-1.diff.gz sensors-applet_1.5.2-1.dsc to pool/main/s/sensors-applet/sensors-applet_1.5.2-1.dsc sensors-applet_1.5.2-1_powerpc.deb to pool/main/s/sensors-applet/sensors-applet_1.5.2-1_powerpc.deb sensors-applet_1.5.2.orig.tar.gz to pool/main/s/sensors-applet/sensors-applet_1.5.2.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted licq 1.3.2-1 (source i386 all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Tue, 1 Nov 2005 15:34:31 +0100 Source: licq Binary: licq licq-plugin-kde licq-plugin-rms licq-plugin-console licq-dev licq-plugin-osd licq-plugin-qt licq-plugin-forwarder licq-plugin-autoreply Architecture: source i386 all Version: 1.3.2-1 Distribution: experimental Urgency: low Maintainer: Peter Eisentraut [EMAIL PROTECTED] Changed-By: Peter Eisentraut [EMAIL PROTECTED] Description: licq - ICQ client (base files) licq-dev - Licq development and header files licq-plugin-autoreply - autoreply plug-in for Licq licq-plugin-console - console user interface plug-in for Licq licq-plugin-forwarder - forwarder plug-in for Licq licq-plugin-kde - graphical user interface plug-in for Licq using Qt and KDE licq-plugin-osd - on-screen display plug-in for Licq licq-plugin-qt - graphical user interface plug-in for Licq using Qt licq-plugin-rms - remote management server plug-in for telnet Licq access Closes: 326430 336427 Changes: licq (1.3.2-1) experimental; urgency=low . * New upstream release (closes: #336427) - Obsoletes: 32_licq-osd-makefile.dpatch * Added 40_licq-forwarder-fix patch * Fixed watch file to filter out RC versions * Removed libtool build dependency * Added build dependency on libxss-dev (closes: #326430) * Great rules simplification; switched to CDBS, simple-patchsys Files: 4f39d6494074d24b7f5d99263e0503cf 915 net optional licq_1.3.2-1.dsc a92ba1ca9fb46eacb2a39419a7371d17 5765250 net optional licq_1.3.2.orig.tar.gz 966db40f2c3d8063fe829086274cd8b2 23979 net optional licq_1.3.2-1.diff.gz 281762a3f839db07fa0e430b1d6814ca 96100 devel optional licq-dev_1.3.2-1_all.deb 2083d80f2d698752e8e0c3b913b30b1f 628376 net optional licq_1.3.2-1_i386.deb 9f1d3515d6ca031b41ed839e125cddb7 46616 net optional licq-plugin-autoreply_1.3.2-1_i386.deb 982b67bc2380521495e4114a39090481 86734 net optional licq-plugin-console_1.3.2-1_i386.deb 5f3bb645a05409b8e31b6984a950cd88 47460 net optional licq-plugin-forwarder_1.3.2-1_i386.deb 4135c82514598cd5d1216a65315464c2 1738946 net optional licq-plugin-kde_1.3.2-1_i386.deb 9022843aec3556967fd9efe5fd870780 63782 net optional licq-plugin-osd_1.3.2-1_i386.deb 15015da678dc3c9f0595fc80311899f1 1716014 net optional licq-plugin-qt_1.3.2-1_i386.deb fb9524853bfc76a13c6b18e2f8b6986e 54414 net optional licq-plugin-rms_1.3.2-1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFDZ4McTTx8oVVPtMYRApKOAKCqdOVtU/NbDytyctQksl+wHTDidACfbOfp VNjEQAUiEaFkdDRPKMuDffk= =P+ZF -END PGP SIGNATURE- Accepted: licq-dev_1.3.2-1_all.deb to pool/main/l/licq/licq-dev_1.3.2-1_all.deb licq-plugin-autoreply_1.3.2-1_i386.deb to pool/main/l/licq/licq-plugin-autoreply_1.3.2-1_i386.deb licq-plugin-console_1.3.2-1_i386.deb to pool/main/l/licq/licq-plugin-console_1.3.2-1_i386.deb licq-plugin-forwarder_1.3.2-1_i386.deb to pool/main/l/licq/licq-plugin-forwarder_1.3.2-1_i386.deb licq-plugin-kde_1.3.2-1_i386.deb to pool/main/l/licq/licq-plugin-kde_1.3.2-1_i386.deb licq-plugin-osd_1.3.2-1_i386.deb to pool/main/l/licq/licq-plugin-osd_1.3.2-1_i386.deb licq-plugin-qt_1.3.2-1_i386.deb to pool/main/l/licq/licq-plugin-qt_1.3.2-1_i386.deb licq-plugin-rms_1.3.2-1_i386.deb to pool/main/l/licq/licq-plugin-rms_1.3.2-1_i386.deb licq_1.3.2-1.diff.gz to pool/main/l/licq/licq_1.3.2-1.diff.gz licq_1.3.2-1.dsc to pool/main/l/licq/licq_1.3.2-1.dsc licq_1.3.2-1_i386.deb to pool/main/l/licq/licq_1.3.2-1_i386.deb licq_1.3.2.orig.tar.gz to pool/main/l/licq/licq_1.3.2.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted libcatalyst-model-cdbi-perl 0.10-1 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Tue, 1 Nov 2005 15:55:56 +0100 Source: libcatalyst-model-cdbi-perl Binary: libcatalyst-model-cdbi-perl Architecture: source all Version: 0.10-1 Distribution: unstable Urgency: low Maintainer: Debian Catalyst Maintainers [EMAIL PROTECTED] Changed-By: Florian Ragwitz [EMAIL PROTECTED] Description: libcatalyst-model-cdbi-perl - CDBI Model Class for Catalyst Changes: libcatalyst-model-cdbi-perl (0.10-1) unstable; urgency=low . * New upstream release * New maintainer: Debian Catalyst Maintainers[EMAIL PROTECTED]. Files: 0a2f3df27ea879c0db2ebce33c8a67bb 860 perl optional libcatalyst-model-cdbi-perl_0.10-1.dsc 33f7f9753778272537eee216b82b9236 3300 perl optional libcatalyst-model-cdbi-perl_0.10.orig.tar.gz 46995214c454eb2181e0c69e94411f3d 1366 perl optional libcatalyst-model-cdbi-perl_0.10-1.diff.gz 97a23c9fafef42b161cb81bed083c811 9028 perl optional libcatalyst-model-cdbi-perl_0.10-1_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDZ4XKdC8qQo5jWl4RAs54AJ9HbSpE3u4kj48dyyFewQtmv7np9QCdG6LH Hm1PybrQEEgezYYKH5FVKnk= =On/f -END PGP SIGNATURE- Accepted: libcatalyst-model-cdbi-perl_0.10-1.diff.gz to pool/main/libc/libcatalyst-model-cdbi-perl/libcatalyst-model-cdbi-perl_0.10-1.diff.gz libcatalyst-model-cdbi-perl_0.10-1.dsc to pool/main/libc/libcatalyst-model-cdbi-perl/libcatalyst-model-cdbi-perl_0.10-1.dsc libcatalyst-model-cdbi-perl_0.10-1_all.deb to pool/main/libc/libcatalyst-model-cdbi-perl/libcatalyst-model-cdbi-perl_0.10-1_all.deb libcatalyst-model-cdbi-perl_0.10.orig.tar.gz to pool/main/libc/libcatalyst-model-cdbi-perl/libcatalyst-model-cdbi-perl_0.10.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted shadow 1:4.0.13-4 (source all i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Tue, 1 Nov 2005 13:04:09 +0100 Source: shadow Binary: login passwd initial-passwd-udeb Architecture: source all i386 Version: 1:4.0.13-4 Distribution: unstable Urgency: low Maintainer: Shadow package maintainers [EMAIL PROTECTED] Changed-By: Christian Perrier [EMAIL PROTECTED] Description: initial-passwd-udeb - Set up users and passwords (udeb) login - system login tools passwd - change and administer password and group data Closes: 260149 333138 Changes: shadow (1:4.0.13-4) unstable; urgency=low . * The Comté release (let's make Nicolas happy) * Debian packaging fixes: - initial-passwd-udeb: Grab last version of Ubuntu code to get rid of the mktemp error This virtually closes bug 336321 but we keep it opened to be sure that noone imagines pushing this version to testing. * Upstream fixes which will reach next upstream version - 467_usermod_longopts: add long options support to usermod. Closes: #260149 - 366_fflush-prompt: fflush prompts to allow scripting. Closes: #333138 Files: e4717ea023786251d3ca34066b334a45 888 admin required shadow_4.0.13-4.dsc f25320bf091ba40fbc7d51de1e97ad77 192338 admin required shadow_4.0.13-4.diff.gz 2276175c265ca91cf8645d0f54db5a8b 612318 admin required passwd_4.0.13-4_i386.deb 364cd4eae7fb9300ce27736b0fb5b452 561788 admin required login_4.0.13-4_i386.deb 6972a251cec8544735d0428aea9edc94 57204 debian-installer extra initial-passwd-udeb_4.0.13-4_all.udeb Package-Type: udeb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDZ5ID1OXtrMAUPS0RAgOUAKCFX6lLyyj7ekfM5C2oGmYQOWzbDQCfYnk4 +PK+LoBt+gw8QQiTJhNSGus= =zjco -END PGP SIGNATURE- Accepted: initial-passwd-udeb_4.0.13-4_all.udeb to pool/main/s/shadow/initial-passwd-udeb_4.0.13-4_all.udeb login_4.0.13-4_i386.deb to pool/main/s/shadow/login_4.0.13-4_i386.deb passwd_4.0.13-4_i386.deb to pool/main/s/shadow/passwd_4.0.13-4_i386.deb shadow_4.0.13-4.diff.gz to pool/main/s/shadow/shadow_4.0.13-4.diff.gz shadow_4.0.13-4.dsc to pool/main/s/shadow/shadow_4.0.13-4.dsc -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted flow-tools 1:0.68-7 (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Tue, 1 Nov 2005 14:37:54 +0200 Source: flow-tools Binary: libcflow-perl flow-tools flow-tools-dev Architecture: source i386 Version: 1:0.68-7 Distribution: unstable Urgency: low Maintainer: Radu Spineanu [EMAIL PROTECTED] Changed-By: Radu Spineanu [EMAIL PROTECTED] Description: flow-tools - collects and processes NetFlow data flow-tools-dev - development files for flow-tools libcflow-perl - perl module for analyzing raw IP flow files written by cflowd Closes: 330951 Changes: flow-tools (1:0.68-7) unstable; urgency=low . * And another amd64 fix, incorrect print of capture times in flow-print and flow-report. Thanks to Oleg Milaenko [EMAIL PROTECTED]. (closes: #330951) Files: c78629216ad0725ec4b0681d7e0e1fd2 815 net optional flow-tools_0.68-7.dsc b7ae7bcbc8971cb9310a7f689438d919 14536 net optional flow-tools_0.68-7.diff.gz ccee44d46f9c365015c281a50b398e2c 1159972 net optional flow-tools_0.68-7_i386.deb 541c8dad0519dd6839a5dc36b044da7b 203132 libdevel optional flow-tools-dev_0.68-7_i386.deb 7d0cc230b4a1546572a31923de479e3a 79918 perl optional libcflow-perl_0.68-7_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDZ2JPJkMZOMmr+9MRAu2NAJ9qkMAuWrmOyQaw9Mq3/MNNjGH3+ACfa5G1 vj1SXdBrNMoyfbYMLXNhaTg= =Khf+ -END PGP SIGNATURE- Accepted: flow-tools-dev_0.68-7_i386.deb to pool/main/f/flow-tools/flow-tools-dev_0.68-7_i386.deb flow-tools_0.68-7.diff.gz to pool/main/f/flow-tools/flow-tools_0.68-7.diff.gz flow-tools_0.68-7.dsc to pool/main/f/flow-tools/flow-tools_0.68-7.dsc flow-tools_0.68-7_i386.deb to pool/main/f/flow-tools/flow-tools_0.68-7_i386.deb libcflow-perl_0.68-7_i386.deb to pool/main/f/flow-tools/libcflow-perl_0.68-7_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted loop-aes-source 3.1b-6 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Tue, 1 Nov 2005 16:50:47 +0100 Source: loop-aes-source Binary: loop-aes-source Architecture: source all Version: 3.1b-6 Distribution: unstable Urgency: low Maintainer: Max Vozeler [EMAIL PROTECTED] Changed-By: Max Vozeler [EMAIL PROTECTED] Description: loop-aes-source - loop-AES encryption Linux kernel modules (source) Changes: loop-aes-source (3.1b-6) unstable; urgency=low . * This version can build with -headers * Generate module dependencies also for non-running kernels (inspired by alsa-driver) * Remove code for upgrading from pre-sarge versions Files: 673d26d06f5e342b362cf060d53e0cb0 599 admin optional loop-aes-source_3.1b-6.dsc c39db391c498314b2e964febc990128e 11976 admin optional loop-aes-source_3.1b-6.diff.gz aae322090a7ec52ca0f20c685fc29a03 246254 admin optional loop-aes-source_3.1b-6_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDZ533nVvVEbfNotwRAkMTAKCJ9XJtpsQUL0uDoenj05kTa1m0YQCgouFI BygHWGnaJQkgQuWopnUmIn0= =duvM -END PGP SIGNATURE- Accepted: loop-aes-source_3.1b-6.diff.gz to pool/main/l/loop-aes-source/loop-aes-source_3.1b-6.diff.gz loop-aes-source_3.1b-6.dsc to pool/main/l/loop-aes-source/loop-aes-source_3.1b-6.dsc loop-aes-source_3.1b-6_all.deb to pool/main/l/loop-aes-source/loop-aes-source_3.1b-6_all.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted loop-aes-modules 3.1b+6 (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Tue, 1 Nov 2005 12:54:57 +0100 Source: loop-aes-modules Binary: loop-aes-2.6.12-1-q40 loop-aes-2.6.12-1-686-smp loop-aes-2.6-parisc loop-aes-2.6-q40 loop-aes-2.6.12-1-powerpc64-di loop-aes-2.6-itanium-smp loop-aes-2.6.12-1-powerpc-di loop-aes-2.6.12-1-sparc64 loop-aes-2.6-bvme6000 loop-aes-2.6-powerpc-smp loop-aes-2.6.12-1-powerpc64 loop-aes-2.6.12-1-mac loop-aes-2.6-atari loop-aes-2.6.12-1-itanium-smp-di loop-aes-2.6-sun3 loop-aes-2.6.12-1-686 loop-aes-2.6.12-1-mckinley-smp loop-aes-2.6-sparc64 loop-aes-2.6-mckinley-smp loop-aes-2.6.12-1-parisc64-smp loop-aes-2.6-powerpc loop-aes-2.6.12-1-hp loop-aes-2.6.12-1-mvme16x loop-aes-2.6-powerpc64 loop-aes-2.6.12-1-atari-di loop-aes-2.6.12-1-k7-smp loop-aes-2.6.12-1-mvme147 loop-aes-2.6.12-1-mvme16x-di loop-aes-2.6.12-1-parisc-di loop-aes-2.6.12-1-itanium-smp loop-aes-2.6-itanium loop-aes-2.6-parisc64-smp loop-aes-2.6.12-1-q40-di loop-aes-2.6-k7 loop-aes-2.6.12-1-parisc-smp loop-aes-2.6.12-1-bvme6000 loop-aes-2.6-mvme16x loop-aes-2.6.12-1-bvme6000-di loop-aes-2.6.12-1-sun3-di loop-aes-2.6.12-1-sun3 loop-aes-2.6-686 loop-aes-2.6-mac loop-aes-2.6-mckinley loop-aes-2.6.12-1-amiga loop-aes-2.6-amiga loop-aes-2.6.12-1-mac-di loop-aes-2.6.12-1-powerpc-smp loop-aes-2.6-parisc64 loop-aes-2.6-mvme147 loop-aes-2.6.12-1-hp-di loop-aes-2.6.12-1-sparc64-di loop-aes-2.6-686-smp loop-aes-2.6.12-1-mvme147-di loop-aes-2.6-386 loop-aes-2.6.12-1-powerpc loop-aes-2.6.12-1-amiga-di loop-aes-2.6.12-1-386 loop-aes-2.6-parisc-smp loop-aes-2.6-k7-smp loop-aes-2.6.12-1-parisc64-di loop-aes-2.6.12-1-itanium loop-aes-2.6.12-1-k7 loop-aes-2.6.12-1-parisc loop-aes-2.6-sparc64-smp loop-aes-2.6.12-1-parisc64 loop-aes-2.6.12-1-mckinley loop-aes-2.6.12-1-sparc64-smp loop-aes-2.6.12-1-386-di loop-aes-2.6.12-1-atari loop-aes-2.6-hp Architecture: source i386 Version: 3.1b+6 Distribution: experimental Urgency: low Maintainer: Max Vozeler [EMAIL PROTECTED] Changed-By: Max Vozeler [EMAIL PROTECTED] Description: loop-aes-2.6-386 - loop-AES modules for kernel 2.6-386 loop-aes-2.6-686 - loop-AES modules for kernel 2.6-686 loop-aes-2.6-686-smp - loop-AES modules for kernel 2.6-686-smp loop-aes-2.6-k7 - loop-AES modules for kernel 2.6-k7 loop-aes-2.6-k7-smp - loop-AES modules for kernel 2.6-k7-smp loop-aes-2.6.12-1-386 - loop-AES encryption Linux kernel modules loop-aes-2.6.12-1-386-di - loop-AES encryption Linux kernel modules (udeb) loop-aes-2.6.12-1-686 - loop-AES encryption Linux kernel modules loop-aes-2.6.12-1-686-smp - loop-AES encryption Linux kernel modules loop-aes-2.6.12-1-k7 - loop-AES encryption Linux kernel modules loop-aes-2.6.12-1-k7-smp - loop-AES encryption Linux kernel modules Changes: loop-aes-modules (3.1b+6) experimental; urgency=low . * Rebuild using loop-aes-source 3.1b-6 * Use headers from /lib/modules/$KVERS/build * Use DH_OPTIONS instead of sed on control file * Architecture changes: + ia64 m68k hppa: Added + arm alpha: Dropped, no 2.6 -di kernels exist currently Files: 62b0090e37226c9f98471523554fce7f 3465 admin optional loop-aes-modules_3.1b+6.dsc 99d408523f9caa0f824fc4af5bd8 7035 admin optional loop-aes-modules_3.1b+6.tar.gz 0968ec7df436fba7ececfa0969a30cb8 2038 admin optional loop-aes-2.6-386_3.1b+6_i386.deb f9c3cfd5f2f1f68790a5196bf60a8aea 2036 admin optional loop-aes-2.6-686_3.1b+6_i386.deb 07c8f8efb41641fdf2fbfc462bd1b92a 2036 admin optional loop-aes-2.6-686-smp_3.1b+6_i386.deb 9b63fc08b2a65d96ea762b6ec8655392 2032 admin optional loop-aes-2.6-k7_3.1b+6_i386.deb a179397b40cf1221d5aaf6e0580d80a4 2038 admin optional loop-aes-2.6-k7-smp_3.1b+6_i386.deb 9a0ab62eaff649fd0a7bb7b576f0e785 102928 admin optional loop-aes-2.6.12-1-386_3.1b+6_i386.deb d540b560b17e29d487a818f13203b9ec 105642 admin optional loop-aes-2.6.12-1-686_3.1b+6_i386.deb 7534cde1958ff361f7a58545a6f1d6aa 106982 admin optional loop-aes-2.6.12-1-686-smp_3.1b+6_i386.deb 82ae6b6df14918a722ae558f647adf7a 105466 admin optional loop-aes-2.6.12-1-k7_3.1b+6_i386.deb 422d023272544c303b4e4fb30b94b3b0 106716 admin optional loop-aes-2.6.12-1-k7-smp_3.1b+6_i386.deb af336a32ca8109c657fe96bb3c9c9858 48534 debian-installer optional loop-aes-2.6.12-1-386-di_3.1b+6_i386.udeb Package-Type: udeb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDZ6AcnVvVEbfNotwRAr+nAJ9rOuWF73DUpAgIWBYCGruAM19xWQCfQPos csiJCs42hMQ2xwyp3j3r2n4= =fPCB -END PGP SIGNATURE- Accepted: loop-aes-2.6-386_3.1b+6_i386.deb to pool/main/l/loop-aes-modules/loop-aes-2.6-386_3.1b+6_i386.deb loop-aes-2.6-686-smp_3.1b+6_i386.deb to pool/main/l/loop-aes-modules/loop-aes-2.6-686-smp_3.1b+6_i386.deb loop-aes-2.6-686_3.1b+6_i386.deb to pool/main/l/loop-aes-modules/loop-aes-2.6-686_3.1b+6_i386.deb loop-aes-2.6-k7-smp_3.1b+6_i386.deb to pool/main/l/loop-aes-modules/loop-aes-2.6-k7-smp_3.1b+6_i386.deb loop-aes-2.6-k7_3.1b+6_i386.deb to
Accepted mozilla-thunderbird-locale-pl 1.0.7-1 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Tue, 1 Nov 2005 18:18:16 +0100 Source: mozilla-thunderbird-locale-pl Binary: mozilla-thunderbird-locale-pl Architecture: source all Version: 1.0.7-1 Distribution: unstable Urgency: low Maintainer: Robert Luberda [EMAIL PROTECTED] Changed-By: Robert Luberda [EMAIL PROTECTED] Description: mozilla-thunderbird-locale-pl - Mozilla Thunderbird Polish Language/Region Package Changes: mozilla-thunderbird-locale-pl (1.0.7-1) unstable; urgency=low . * New upstream version. * Standards-Version: 3.6.2. * Updated debian/watch, but unfortunatelly it doesn't seem to work anyway. Files: 232dc3d3c5583898b0cca1d5f3066be8 715 web optional mozilla-thunderbird-locale-pl_1.0.7-1.dsc 76e4160055304c22dd1e35954ae3a905 308952 web optional mozilla-thunderbird-locale-pl_1.0.7.orig.tar.gz 581089eed5bd7a15247b2c4bbc213823 10769 web optional mozilla-thunderbird-locale-pl_1.0.7-1.diff.gz c667ee4e6e38dc5d2f02b9db5d8531cd 319514 web optional mozilla-thunderbird-locale-pl_1.0.7-1_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDZ6W7Thh1cJ0wnDsRAreyAJ4rdO+VIl1H9xTr62fzaRY672GZnQCfWk5Z pDyeLKcD4nazH7vf3Y3ux4o= =7hT3 -END PGP SIGNATURE- Accepted: mozilla-thunderbird-locale-pl_1.0.7-1.diff.gz to pool/main/m/mozilla-thunderbird-locale-pl/mozilla-thunderbird-locale-pl_1.0.7-1.diff.gz mozilla-thunderbird-locale-pl_1.0.7-1.dsc to pool/main/m/mozilla-thunderbird-locale-pl/mozilla-thunderbird-locale-pl_1.0.7-1.dsc mozilla-thunderbird-locale-pl_1.0.7-1_all.deb to pool/main/m/mozilla-thunderbird-locale-pl/mozilla-thunderbird-locale-pl_1.0.7-1_all.deb mozilla-thunderbird-locale-pl_1.0.7.orig.tar.gz to pool/main/m/mozilla-thunderbird-locale-pl/mozilla-thunderbird-locale-pl_1.0.7.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted cpufreqd 1.999+2.0pre2-1 (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Tue, 01 Nov 2005 16:08:38 +0100 Source: cpufreqd Binary: cpufreqd Architecture: source i386 Version: 1.999+2.0pre2-1 Distribution: unstable Urgency: low Maintainer: Mattia Dongili [EMAIL PROTECTED] Changed-By: Mattia Dongili [EMAIL PROTECTED] Description: cpufreqd - fully configurable daemon for dynamic frequency and voltage scali Closes: 239946 298645 330409 333617 334559 Changes: cpufreqd (1.999+2.0pre2-1) unstable; urgency=low . * New upstream release. * Now suggest cpufrequtils (closes: #333617) * The new plugin architecture allows: - for easy selection of resources to poll (closes: #239946) - polling of ACPI thermal zones (closes: #298645) * Added Spanish translation (closes: #334559) * Added Swedish translation (closes: #330409) Files: 14af8969ac148490337271d8e525e062 659 admin optional cpufreqd_1.999+2.0pre2-1.dsc 7f1ffe0d20657c2bd66438383790b0eb 371239 admin optional cpufreqd_1.999+2.0pre2.orig.tar.gz d6032a18f086091a1df1b216db4a3af0 11340 admin optional cpufreqd_1.999+2.0pre2-1.diff.gz 60c3719ed94800d8577dbca2f8a4efb5 62434 admin optional cpufreqd_1.999+2.0pre2-1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFDZ6XxgpRPaOotLEERAnSlAJ9VVQZ3Ldejq602fVvi6Cfz1xydSACfalMm u7Sev0Z397TexVjEYa4eGPY= =g81c -END PGP SIGNATURE- Accepted: cpufreqd_1.999+2.0pre2-1.diff.gz to pool/main/c/cpufreqd/cpufreqd_1.999+2.0pre2-1.diff.gz cpufreqd_1.999+2.0pre2-1.dsc to pool/main/c/cpufreqd/cpufreqd_1.999+2.0pre2-1.dsc cpufreqd_1.999+2.0pre2-1_i386.deb to pool/main/c/cpufreqd/cpufreqd_1.999+2.0pre2-1_i386.deb cpufreqd_1.999+2.0pre2.orig.tar.gz to pool/main/c/cpufreqd/cpufreqd_1.999+2.0pre2.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted yydecode 0.2.10-2 (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Tue, 1 Nov 2005 18:02:20 +0100 Source: yydecode Binary: yydecode Architecture: source i386 Version: 0.2.10-2 Distribution: unstable Urgency: medium Maintainer: Debian QA Group [EMAIL PROTECTED] Changed-By: Matej Vela [EMAIL PROTECTED] Description: yydecode - decode yEnc archives Closes: 177370 262755 Changes: yydecode (0.2.10-2) unstable; urgency=low . * QA upload. * New upstream release (0.2.10 and 0.2.10-1 were unofficial releases by the upstream author). Closes: #262755. * debian/rules: - Use distclean rather than maintainer-clean to avoid regenerating configure etc. - Add support for DEB_BUILD_OPTIONS=noopt. - Remove support for DEB_BUILD_OPTIONS=debug. - Let dh_strip handle DEB_BUILD_OPTIONS=nostrip. * debian/watch: Add. * Conforms to Standards version 3.6.2. . yydecode (0.2.10-1) unstable; urgency=low . * It's probably better staying a non-native package... * Compile with large file support. (Closes: #177370) . yydecode (0.2.10) unstable; urgency=medium . * New maintainer! (me!) * New upstream, now a Debian native package. Files: 174c8c8480f10866785992c82f08b5bb 575 utils optional yydecode_0.2.10-2.dsc 9e6c5eb009f9084f7cbe7e4b766b12d8 119983 utils optional yydecode_0.2.10.orig.tar.gz b97703c722c2c614936c17d51ddc5c06 1076 utils optional yydecode_0.2.10-2.diff.gz 3b1efebddf52e9908353bd502a7db8d4 21646 utils optional yydecode_0.2.10-2_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDZ6RexBYivKllgY8RAoAFAJ9inHRkRi5ReBmSszH337zAxKFnpgCg28Rb CR5SAv1XG/i4bNWO1VGAst0= =MucE -END PGP SIGNATURE- Accepted: yydecode_0.2.10-2.diff.gz to pool/main/y/yydecode/yydecode_0.2.10-2.diff.gz yydecode_0.2.10-2.dsc to pool/main/y/yydecode/yydecode_0.2.10-2.dsc yydecode_0.2.10-2_i386.deb to pool/main/y/yydecode/yydecode_0.2.10-2_i386.deb yydecode_0.2.10.orig.tar.gz to pool/main/y/yydecode/yydecode_0.2.10.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted bogofilter 0.96.4-1 (source sparc)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Tue, 1 Nov 2005 12:52:45 -0500 Source: bogofilter Binary: bogofilter-qdbm bogofilter-bdb bogofilter bogofilter-common bogofilter-sqlite Architecture: source sparc Version: 0.96.4-1 Distribution: unstable Urgency: high Maintainer: Clint Adams [EMAIL PROTECTED] Changed-By: Clint Adams [EMAIL PROTECTED] Description: bogofilter - a fast Bayesian spam filter (dummy package) bogofilter-bdb - a fast Bayesian spam filter (Berkeley DB) bogofilter-common - a fast Bayesian spam filter (common files) bogofilter-qdbm - a fast Bayesian spam filter (QDBM) bogofilter-sqlite - a fast Bayesian spam filter (sqlite) Changes: bogofilter (0.96.4-1) unstable; urgency=high . * New upstream current release. Files: f0a2e4345ae3dc3860b72dc1b66bd310 697 mail optional bogofilter_0.96.4-1.dsc df4259e3c3644b4895e676212d901ef2 882720 mail optional bogofilter_0.96.4.orig.tar.gz 4febaa8125a402f13fa2405b592e8bbb 10600 mail optional bogofilter_0.96.4-1.diff.gz 0f7e831c37fcbf7f811820847f7a74b5 936 mail optional bogofilter_0.96.4-1_sparc.deb 6d40e7979282abe81f772f59c8004334 252892 mail optional bogofilter-bdb_0.96.4-1_sparc.deb 4d9cd544715cf12d0a08b4547f7797b6 226474 mail optional bogofilter-qdbm_0.96.4-1_sparc.deb 6e3da2bf776eeade68b91976587c6321 226806 mail optional bogofilter-sqlite_0.96.4-1_sparc.deb 68073b3de988a540960fe29e03b0daca 158168 mail optional bogofilter-common_0.96.4-1_sparc.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Debian! iD8DBQFDZ7J95m0u66uWM3ARAvIEAJ9IxXze7W/8+eGTdWPAMkIpludxGACcC4hv 9spqfdFB0tNzK8TNKGuBY0U= =4zAe -END PGP SIGNATURE- Accepted: bogofilter-bdb_0.96.4-1_sparc.deb to pool/main/b/bogofilter/bogofilter-bdb_0.96.4-1_sparc.deb bogofilter-common_0.96.4-1_sparc.deb to pool/main/b/bogofilter/bogofilter-common_0.96.4-1_sparc.deb bogofilter-qdbm_0.96.4-1_sparc.deb to pool/main/b/bogofilter/bogofilter-qdbm_0.96.4-1_sparc.deb bogofilter-sqlite_0.96.4-1_sparc.deb to pool/main/b/bogofilter/bogofilter-sqlite_0.96.4-1_sparc.deb bogofilter_0.96.4-1.diff.gz to pool/main/b/bogofilter/bogofilter_0.96.4-1.diff.gz bogofilter_0.96.4-1.dsc to pool/main/b/bogofilter/bogofilter_0.96.4-1.dsc bogofilter_0.96.4-1_sparc.deb to pool/main/b/bogofilter/bogofilter_0.96.4-1_sparc.deb bogofilter_0.96.4.orig.tar.gz to pool/main/b/bogofilter/bogofilter_0.96.4.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted libgsf 1.13.2-2 (source all i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Tue, 1 Nov 2005 18:54:14 +0100 Source: libgsf Binary: libgsf-1-113 libgsf-1-common libgsf-1-113-dbg libgsf-bin libgsf-gnome-1-113-dbg libgsf-gnome-1-dev libgsf-1-dev libgsf-gnome-1-113 Architecture: source all i386 Version: 1.13.2-2 Distribution: unstable Urgency: low Maintainer: J.H.M. Dassen (Ray) [EMAIL PROTECTED] Changed-By: J.H.M. Dassen (Ray) [EMAIL PROTECTED] Description: libgsf-1-113 - Structured File Library - runtime version libgsf-1-113-dbg - Structured File Library - debugging files (basic version) libgsf-1-common - Structured File Library - common files libgsf-1-dev - Structured File Library - development files (basic version) libgsf-bin - Structured File Library - programs libgsf-gnome-1-113 - Structured File Library - runtime version for GNOME libgsf-gnome-1-113-dbg - Structured File Library - debugging files for GNOME libgsf-gnome-1-dev - Structured File Library - development files for GNOME Changes: libgsf (1.13.2-2) unstable; urgency=low . * Upload to unstable. Files: a5d98ac4232becef7fa66da641205cf6 872 libs optional libgsf_1.13.2-2.dsc 0eb2a03ab259b661cb05cf3c3e7cba49 8190 libs optional libgsf_1.13.2-2.diff.gz 191c51c13065d334ac123e3400f05359 56792 libdevel optional libgsf-gnome-1-dev_1.13.2-2_i386.deb 3a47d6096eb29182d94144775b9b8455 9732 libdevel extra libgsf-gnome-1-113-dbg_1.13.2-2_i386.deb ec78ddabcc025a92a726658f53649e87 49352 libs optional libgsf-gnome-1-113_1.13.2-2_i386.deb eba81dee2f61ee39e9ef7ebb5eb6a0e9 90264 libdevel extra libgsf-1-113-dbg_1.13.2-2_i386.deb 074cccf6a60f32f5c863e0c87dec7907 220338 libdevel optional libgsf-1-dev_1.13.2-2_i386.deb 00091194ad0603b6a3e01ac5631c0536 116948 libs optional libgsf-1-113_1.13.2-2_i386.deb 23c6047495ddc8f6c2d943ae01d8b1f5 42760 libs optional libgsf-1-common_1.13.2-2_all.deb 6548318db7d2e02c153b4eaad673109a 48058 gnome optional libgsf-bin_1.13.2-2_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDZ7IWA+HB2Re6Rc4RAm2RAKChtSkHoX7grtPaCarKzFGMeUBghACeLQ2C ITRrvkEiRIXHqBGHAWAMi5Y= =kOHB -END PGP SIGNATURE- Accepted: libgsf-1-113-dbg_1.13.2-2_i386.deb to pool/main/libg/libgsf/libgsf-1-113-dbg_1.13.2-2_i386.deb libgsf-1-113_1.13.2-2_i386.deb to pool/main/libg/libgsf/libgsf-1-113_1.13.2-2_i386.deb libgsf-1-common_1.13.2-2_all.deb to pool/main/libg/libgsf/libgsf-1-common_1.13.2-2_all.deb libgsf-1-dev_1.13.2-2_i386.deb to pool/main/libg/libgsf/libgsf-1-dev_1.13.2-2_i386.deb libgsf-bin_1.13.2-2_i386.deb to pool/main/libg/libgsf/libgsf-bin_1.13.2-2_i386.deb libgsf-gnome-1-113-dbg_1.13.2-2_i386.deb to pool/main/libg/libgsf/libgsf-gnome-1-113-dbg_1.13.2-2_i386.deb libgsf-gnome-1-113_1.13.2-2_i386.deb to pool/main/libg/libgsf/libgsf-gnome-1-113_1.13.2-2_i386.deb libgsf-gnome-1-dev_1.13.2-2_i386.deb to pool/main/libg/libgsf/libgsf-gnome-1-dev_1.13.2-2_i386.deb libgsf_1.13.2-2.diff.gz to pool/main/libg/libgsf/libgsf_1.13.2-2.diff.gz libgsf_1.13.2-2.dsc to pool/main/libg/libgsf/libgsf_1.13.2-2.dsc -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
