Re: I am still on the keyring. With my old key.
* Marc Haber [EMAIL PROTECTED] [2005-11-21 08:55:52]: On Sun, 20 Nov 2005 11:29:19 +0100, Petter Reinholdtsen [EMAIL PROTECTED] wrote: I seriously hope the non-elected people blocking and slowing down several important processes in Debian soon realize that there is a problem and that it might be best for them to solve it by stepping aside or allowing new people to help them with the tasks. I have lost _that_ hope like two years ago. It is not the case that these problems with the non-elected people who keep blocking processes are new. No, they have been there even when I joined the project. i have not given up that hope yet and i invest a considerable amount of time working on this issue as part of my work on the DPL-Team. others there do so, too. signature.asc Description: Digital signature
Re: I am still on the keyring. With my old key.
2005/11/21, Henning Makholm [EMAIL PROTECTED]: It can be considered bad from a technical viewpoint - as far as I understand the master copy of the keyring is currently on a medium that is under the keyring maintainer's direct physical control. The obvious way of switching to team maintenance of the keyring would entail keeping the master copy in a central machine - for example on a debian.org box somewhere in a colo. Doing that in a way that does not leave the keyring more vulnerable to surreptitious compromise than some reasonable persons might prefer, requires software support that does not currently exist. Thanks for the clear explanation, I certainly hadn't heard that argument before. My first thought would be to simply create multiple keyrings, one for each keyring maintainer, which are merged on a regular basis. Teaching the archive scripts to look at more than one keyring wouldn't be too hard. Anyway, surely the acceptance onto the keyring is designated by a signiture on that key, not just by it's presense in a particular file? How do you ensure the file hasn't been tampered with? Signitures can be revoked, but only by the person who signed it in the first place. Anyway, my GPG knowledge isn't that great. so I'll leave it at that. Thanks for the info.
ITP: pykdeextensions -- Python packages to support KDE applications (scripts)
Package: wnpp Severity: wishlist Owner: Fathi Boudra [EMAIL PROTECTED] * Package name: pykdeextensions Version : 0.3.0 Upstream Author : Simon Edwards [EMAIL PROTECTED] * URL : http://www.simonzone.com/software/pykdeextensions * License : GPL Description : Python packages to support KDE applications (scripts) PyKDE Extensions is a collection of software and Python packages to support the creation and installation of KDE applications. the same source provides also libpythonize0 package. cheers, Fathi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
ITP: libpythonize -- Python packages to support KDE applications (library)
Package: wnpp Severity: wishlist Owner: Fathi Boudra [EMAIL PROTECTED] * Package name: libpythonize Version : 0.3.0 Upstream Author : Simon Edwards [EMAIL PROTECTED] * URL : http://www.simonzone.com/software/pykdeextensions * License : GPL Description : Python packages to support KDE applications (library) PyKDE Extensions is a collection of software and Python packages to support the creation and installation of KDE applications. This package contains the libpythonize library files. the same source provides also pykdeextensions package. (see also Bug#340141) cheers, Fathi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
status of vore?
Hello, I would need to have access to a sid chroot on sparc to build sbcl by hand, but vore seems to be unreachable by me. The machine page [1] shows no indication of problems, it is outdated? Groetjes, Peter 1: http://db.debian.org/machines.cgi?host=vore -- signature -at- pvaneynd.mailworks.org http://www.livejournal.com/users/pvaneynd/ God, root, what is difference? Pitr | God is more forgiving. Dave Aronson| pgpcW2wChqwnG.pgp Description: PGP signature
ITP: kde-guidance -- collection of KDE system administration tools for GNU/Linux
Package: wnpp Severity: wishlist Owner: Fathi Boudra [EMAIL PROTECTED] * Package name: kde-guidance Version : 0.4.0 Upstream Author : Simon Edwards [EMAIL PROTECTED] * URL : http://www.simonzone.com/software/guidance * License : GPL Description : collection of KDE system administration tools for GNU/Linux Guidance is a collection of KDE system administration tools for GNU/Linux systems. Guidance currently consists of three programs designed to help you look after your system : - userconfig - User and Group administration - serviceconfig - Service/daemon administration - mountconfig - Disk and filesystem administration Guidance needs pykdeextensions. (see also Bug#340141 and Bug#340142) cheers, Fathi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Conffiles and possible conffiles
Hi, on the debian-tetex-maint mailing list we often have problems to decide which of the thousands of TeX input files should be treated as configuration files - in principle, each of them can be changed in order to change the behavior of the system. We are currently thinking about a solution were there would be hardly any conffiles[1], but a local admin could put copies of any file he likes into subdirectories of /etc/texmf. This would shadow the dpkg-shipped file in /usr/share/texmf and allow configuration. And of course we would document this. There is one major drawback, however: If a file that has a (changed) copy in /etc/texmf is changed in the deb, the user gets no notification. This is at least annoying - but on the other hand, many users have newer or changed versions in /usr/local/share/texmf or in $HOME/texmf, and they face the same problem. What do others think? Would it be acceptable Policy-wise to handle configuration like this? Regards, Frank [1] The configuration file snippets in /etc/texmf/*.d/ would be kept, as well as configuration files for tetex-bin's programs. -- Frank Küster Inst. f. Biochemie der Univ. Zürich Debian Developer
Re: status of vore?
On Mon, Nov 21, 2005 at 10:10:38AM +0100, Peter Van Eynde wrote: I would need to have access to a sid chroot on sparc to build sbcl by hand, but vore seems to be unreachable by me. The machine page [1] shows no indication of problems, it is outdated? The db.d.o page doesn't get status updates all that frequently, I'm afraid. Yes, vore has been down for a while now -- about three weeks, actually. This leaves us without a porter machine for sparc at present; there's been talk of putting user chroots on auric, but this may be dependent on another sparc buildd being brought on-line (and one is in the works) so that auric isn't doing double-duty as a porter machine and buildd. -- 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: ITP: pykdeextensions -- Python packages to support KDE applications (scripts)
On Mo, 2005-11-21 at 10:17 +0100, Fathi Boudra wrote: Package: wnpp Severity: wishlist Owner: Fathi Boudra [EMAIL PROTECTED] * Package name: pykdeextensions Version : 0.3.0 Upstream Author : Simon Edwards [EMAIL PROTECTED] * URL : http://www.simonzone.com/software/pykdeextensions * License : GPL Description : Python packages to support KDE applications (scripts) PyKDE Extensions is a collection of software and Python packages to support the creation and installation of KDE applications. the same source provides also libpythonize0 package. cheers, Those packages (pykdeextensions, libpythonize and kde-guidance) are already in Ubuntu Breezy (Ubuntu and Kubuntu Flavour). If you're interested, you can have a look into those package and push them into Debian. kde-guidance | 0.4.0-0ubuntu4 | http://archive.ubuntu.com dapper/main Packages kde-guidance | 0.4.0-0ubuntu4 | http://archive.ubuntu.com dapper/main Sources pykdeextensions | 0.4.0-0ubuntu1 | http://archive.ubuntu.com dapper/main Packages pykdeextensions | 0.4.0-0ubuntu1 | http://archive.ubuntu.com dapper/main Sources the libpythonize0 package is being generated from pykdeextensions, because no other package is using it right now. Regards, \sh signature.asc Description: This is a digitally signed message part
Re: ITP: pykdeextensions -- Python packages to support KDE applications (scripts)
Those packages (pykdeextensions, libpythonize and kde-guidance) are already in Ubuntu Breezy (Ubuntu and Kubuntu Flavour). If you're interested, you can have a look into those package and push them into Debian. thanks for the advice but i know this because i've done the base packaging with jonathan riddell of these packages :) I had not made the ITP for debian only ;) so the RFS will follow quickly to push them into debian. cheers, Fathi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: status of vore?
Steve Langasek wrote: On Mon, Nov 21, 2005 at 10:10:38AM +0100, Peter Van Eynde wrote: I would need to have access to a sid chroot on sparc to build sbcl by hand, but vore seems to be unreachable by me. The machine page [1] shows no indication of problems, it is outdated? The db.d.o page doesn't get status updates all that frequently, I'm afraid. Yes, vore has been down for a while now -- about three weeks, actually. This leaves us without a porter machine for sparc at present; there's been talk of putting user chroots on auric, but this may be dependent on another sparc buildd being brought on-line (and one is in the works) so that auric isn't doing double-duty as a porter machine and buildd. I have an Ultra 30 available for devel/test if it'll help. Mail me off-list if you'd like an account. -- Steve McIntyre, Cambridge, UK.[EMAIL PROTECTED] C++ ate my sanity -- Jon Rabone -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Conffiles and possible conffiles
On Nov 21, Frank Küster [EMAIL PROTECTED] wrote: What do others think? Would it be acceptable Policy-wise to handle configuration like this? Yes. -- ciao, Marco signature.asc Description: Digital signature
Re: how to deal with screwed up package
On Nov 19, Adam Borowski [EMAIL PROTECTED] wrote: [udev] edit /etc/udev/permissions.rules (owned by the udev package, and thus out of reach of fuse-utils anyway) Wrong. The correct solution would be to install a new file in /etc/udev/rules.d/. -- ciao, Marco signature.asc Description: Digital signature
Re: I am still on the keyring. With my old key.
On Mon, 21 Nov 2005, Martijn van Oosterhout wrote: Anyway, surely the acceptance onto the keyring is designated by a signiture on that key, not just by it's presense in a particular file? Yes, it *is* the presense in a particular file. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Spliting packages between pkg and pkg-data
On Mon, 21 Nov 2005, Ricardo Mones wrote:
On Sun, 20 Nov 2005 12:13:48 +0100
Bill Allombert [EMAIL PROTECTED] wrote:
When doing research about circular-deps, I looked at a lot of packages
that are split between a binary package and a data package. This is a
good thing since this reduce the total siez of the archive, however
there are simple rules that should be followed:
1) Make sure pkg-data is actually arch: all.
2) Name it in a way that make the relationship obvious: For example,
if the upstream name is 'foo', name the binary package 'foo' and the
data package 'foo-data'.
3) Keep the files that 'signal' executables in the same package than the
executable (e.g. menu file, program manpage).
4) Do not put symlinks in data packages that point to files in the binary
package. This do not really save space and avoid dandling symlinks
when the binary package is not installed.
5) Of course move /usr/share/pkg to pkg-data.
6) Do not make pkg-data to Depends on pkg.
7) Try to do it correctly the first time: if you move file between
pkg and pkg-data, you will need to use Replaces:
Please check your packages follow these rules, and if not, do not forget
about rule 7.
I'd suggest to add this to the best practices for debian/control in
developers' reference. What do you think?
That it is incomplete.
1. -data packages should probably recommend their parent packages if they
are useless without the main package. And versioning should be used if
possible (and needed, don't do it just because), but it cannot be too
strict (= ${Source-Version}) between arch all and arch !all packages,
since that breaks bin-NMUs (which is arguably a minor bug in the whole
bin-NMU concept, or in dpkg's lack of a mostly equal operator that also
matches bin-NMUs).
2. symlinks are just fine if there is a depends to ensure they are not
dangling (and we are not talking about essential binaries, etc). For
optional -data packages, which the main package does _not_ depend on (and
instead suggests or recommends the -data package), it is feasible for
the -data package to depend on the main one and have symlinks to the main
one, and it is not a bad thing at all to use them.
3. Loose dependencies between -data and main packages *CAN* create breakage
on partial upgrades, depending on just how tight the relationship between
a particular version of the package and its arch-indep data is. Watch
out for this, it is NOT always an easy problem to solve because of bin
NMUs.
4. Also IMHO one should at the very least suggest the main package from the
-data package. This helps the users of non-crappy apt frontends to
track the main package starting from the -data package. Relying on
package naming alone for this is suboptimal at best.
--
One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie. -- The Silicon Valley Tarot
Henrique Holschuh
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: master's mail backlog and upgrade time
Hi, Andreas Metzler wrote: The real problem with these bounces is not that they fill up the forwarding host's queue but that they are usually unwanted. Think Joe Job. This thread is about email that is obviously not legitimate just looking at the envelope. In this day and age, everyone does ingress/egress filtering on their networks to enforce just that minimum bit of plausibility, and I feel email systems should do the same. In the last one and a half days a system I administer has rejected 451 emails because of obviously nonexistent envelope addresses, that doesn't count those systems where we don't accept mail from *at all* because they are dialup systems. This, however, is a small system with 10 email addresses total. If legitimate email is rejected because the envelope is obviously broken, I believe it is rightfully so, and the sender of that email is supposed to do something about it. The correct behaviour to notify the sender in this case is to reject the mail at the SMTP level, because this is going to be the last time you have a connection to someone who is responsible in some way or other (either by sending broken emails or by running an email server accepting broken emails). Forwarding email unconditionally makes my debian.org address receive by far the largest amount of spam of all addresses I have. Please, think about the kittens. Simon signature.asc Description: OpenPGP digital signature
Re: Spliting packages between pkg and pkg-data
On Sun, Nov 20, 2005 at 12:13:48PM +0100, Bill Allombert wrote: 5) Of course move /usr/share/pkg to pkg-data. I meant move /usr/share/pkg to the data package, do not rename it. 6) Do not make pkg-data to Depends on pkg. 7) Try to do it correctly the first time: if you move file between pkg and pkg-data, you will need to use Replaces: Daniel Burrows told me about 8) 8) Do not make /usr/share/doc/pkg-data a symlink to /usr/share/doc/pkg, because this would force the dependency pkg-data--pkg Instead you can either move the content of /usr/share/doc/pkg to /usr/share/doc/pkg-data and make /usr/share/doc/pkg a symlink to /usr/share/doc/pkg-data, or you can make /usr/share/doc/pkg-data a copy of /usr/share/doc/pkg. Cheers, -- Bill. [EMAIL PROTECTED] Imagine a large red swirl here. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: master's mail backlog and upgrade time
* Quoting Simon Richter ([EMAIL PROTECTED]): emails because of obviously nonexistent envelope addresses, that doesn't count those systems where we don't accept mail from *at all* because they are dialup systems. This, however, is a small system with 10 email How do you define dialup systems and tell dialup systems from other systems? - Rolf -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: master's mail backlog and upgrade time
Hello, Rolf Kutz wrote: emails because of obviously nonexistent envelope addresses, that doesn't count those systems where we don't accept mail from *at all* because they are dialup systems. This, however, is a small system with 10 email How do you define dialup systems and tell dialup systems from other systems? There is a database where ISPs can register the ranges they assign for dialup users. Simon signature.asc Description: OpenPGP digital signature
Re: Uploading amd64 packages
=?iso-8859-15?Q?J=E9r=F4me_Marant?= [EMAIL PROTECTED] writes: I meantioned one solution. There is another possible one: source uploads. And no, I don't think it would cause more breakages than nowdays because uploading sources only doesn't meant packages have not been build on our systems. -- Jérôme Marant There are some implementation details that someone would have to fix first: 1. DAK refuses source uploads 2. sources without debs get removed so a source only upload would remove itself potentialy before buildds supply debs 3. source uploads would not build architecture all package. None of the buildds will and then they are missing. 4. architecture all uploads are not possible so one would have to upload for e.g. i386 with just arch:all debs. But then the DAK would see that the source stoped building certain binaries (all arch: i386 debs) wrongfully and create problems. So while theoretically source only uploads would be great practically there are problems. I sure hope patches would be welcome though. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Spliting packages between pkg and pkg-data
Nicolas Boullis [EMAIL PROTECTED] writes: On Sun, Nov 20, 2005 at 12:13:48PM +0100, Bill Allombert wrote: Hello Debian developers, When doing research about circular-deps, I looked at a lot of packages that are split between a binary package and a data package. This is a good thing since this reduce the total siez of the archive, however there are simple rules that should be followed: 3) Keep the files that 'signal' executables in the same package than the executable (e.g. menu file, program manpage). Why? I agree that it menu files and manpages are generally not that large, but what would it break to have them in pkg-data? (I would consider it strange to have such files out of the main pkg package, but it looks policy-compliant as far as I can see...) Nicolas foo depends on foo-data. But foo-data does NOT depend on foo. So an apt-get install foo-data, while being useless, is consistent for dpkg. After that you would end up with a menu entry for foo but no foo binary. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Conffiles and possible conffiles
On Mon, Nov 21, 2005 at 11:31:22AM +0100, Frank K?ster wrote: Hi, on the debian-tetex-maint mailing list we often have problems to decide which of the thousands of TeX input files should be treated as configuration files - in principle, each of them can be changed in order to change the behavior of the system. We are currently thinking about a solution were there would be hardly any conffiles[1], but a local admin could put copies of any file he likes into subdirectories of /etc/texmf. This would shadow the dpkg-shipped file in /usr/share/texmf and allow configuration. And of course we would document this. In my opinion, kpathsea offer multi-level override and this is the best way to handle conffiles, so we should take advantage of it. This mean doing what you propose. This is the way Debian menu works: put menu entries in /usr/share/menu, allow the sysadmin to override them in /etc/menu and allow the user to override them in ~/.menu. If I were to redesign Debian/Unix from scratch, I would make 3-way override mandatory. So I think this is a great idea. I was on the verge of proposing that two year ago during the texmf.d flamefest but I though there was an unforeseen reason it could not work. Cheers, -- Bill. [EMAIL PROTECTED] Imagine a large red swirl here. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: My IP address seems listed as a spammer address by bugs.debian.org
Brian M. Carlson wrote: If you need to access the BTS data from a program, there is an LDAP interface available and a copy of entire BTS database on one of the developer accessable machines. Then bts cache should use that, and not HTTP, or perhaps only fall back to HTTP. The LDAP interface is not production quality enough to be used by anything IMHO. It seems to be down or moved to somewhere else half the time. We (devscripts maints) have had to switch other programs (tagpending) away from using it due to these problems. Using the cache would be good, except it's only available to debian developers via ssh. Additionally, the robots.txt is being violated by bts cache, so perhaps someone should file a bug. bts cache is not a web spider, it only downloads the bugs that you tell it to. It violates the robots.txt much less than eg, wget. -- see shy jo
Re: Spliting packages between pkg and pkg-data
On Mon, 2005-11-21 at 16:26 +0100, Goswin von Brederlow wrote: foo depends on foo-data. But foo-data does NOT depend on foo. So an apt-get install foo-data, while being useless, is consistent for dpkg. After that you would end up with a menu entry for foo but no foo binary. If package foo-data is useless when foo is not installed, foo-data should depend on package foo. This follows from policy manual 7.2: The Depends field should be used if the depended-on package is required for the depending package to provide a significant amount of functionality.. Or am I missing something here? Thijs signature.asc Description: This is a digitally signed message part
Re: Spliting packages between pkg and pkg-data
Henrique de Moraes Holschuh [EMAIL PROTECTED] writes: 3. Loose dependencies between -data and main packages *CAN* create breakage on partial upgrades, depending on just how tight the relationship between a particular version of the package and its arch-indep data is. Watch out for this, it is NOT always an easy problem to solve because of bin NMUs. One can provide 'foo-abi-1234' and depend on that. For packages that seldomely change the data format this works fine. For frequent/regular data format changes a Depends: foo-data (= 1.2-3), foo-data ( 1.2-3.1) or ( 1.3) should do the job. A = should be avoided imho. 4. Also IMHO one should at the very least suggest the main package from the -data package. This helps the users of non-crappy apt frontends to track the main package starting from the -data package. Relying on package naming alone for this is suboptimal at best. Actualy I would love to have the naming policy set in stone and frontends filter for them. There is no reason to list foo-data in the package list but only foo. The frontends can do a simple check: if ($PKG depends on $PKG-data) then hide $PKG-data. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Spliting packages between pkg and pkg-data
On Mon, 21 Nov 2005 10:47:18 -0200
Henrique de Moraes Holschuh [EMAIL PROTECTED] wrote:
On Mon, 21 Nov 2005, Ricardo Mones wrote:
On Sun, 20 Nov 2005 12:13:48 +0100
Bill Allombert [EMAIL PROTECTED] wrote:
When doing research about circular-deps, I looked at a lot of
packages that are split between a binary package and a data
package. This is a good thing since this reduce the total siez of
the archive, however there are simple rules that should be
followed:
1) Make sure pkg-data is actually arch: all.
2) Name it in a way that make the relationship obvious: For
example, if the upstream name is 'foo', name the binary package
'foo' and the data package 'foo-data'.
3) Keep the files that 'signal' executables in the same package
than the executable (e.g. menu file, program manpage).
4) Do not put symlinks in data packages that point to files in
the binary package. This do not really save space and avoid
dandling symlinks when the binary package is not installed.
5) Of course move /usr/share/pkg to pkg-data.
6) Do not make pkg-data to Depends on pkg.
7) Try to do it correctly the first time: if you move file between
pkg and pkg-data, you will need to use Replaces:
Please check your packages follow these rules, and if not, do not
forget about rule 7.
I'd suggest to add this to the best practices for debian/control
in developers' reference. What do you think?
That it is incomplete.
I'm glad you decided to complete it :)
1. -data packages should probably recommend their parent packages if
they are useless without the main package. And versioning should be
used if possible (and needed, don't do it just because), but it
cannot be too strict (= ${Source-Version}) between arch all and
arch !all packages, since that breaks bin-NMUs (which is arguably a
minor bug in the whole bin-NMU concept, or in dpkg's lack of a mostly
equal operator that also matches bin-NMUs).
2. symlinks are just fine if there is a depends to ensure they are
not dangling (and we are not talking about essential binaries, etc).
For optional -data packages, which the main package does _not_ depend
on (and instead suggests or recommends the -data package), it is
feasible for the -data package to depend on the main one and have
symlinks to the main one, and it is not a bad thing at all to use
them.
That one rewrites the point 6 above as the opposite, which should
read: there is no problem in pkg-data depending on pkg as long as
you don't make pkg also depend on pkg-data, which triggers the circular
dependency problem.
3. Loose dependencies between -data and main packages *CAN* create
breakage on partial upgrades, depending on just how tight the
relationship between a particular version of the package and its
arch-indep data is. Watch out for this, it is NOT always an easy
problem to solve because of bin NMUs.
Isn't it the same case when packaging external modules (shared
libraries) for a host application? The difference is shared libs are
arch-dependent, of course.
4. Also IMHO one should at the very least suggest the main package
from the -data package. This helps the users of non-crappy apt
frontends to track the main package starting from the -data package.
Relying on package naming alone for this is suboptimal at best.
IMHO pkg-data package should also include an «Enhances: pkg» in
addition to the suggest. Both fields with some partial string matching
on the package names could make some frontend realize the kind
of relation between the packages.
regards,
--
Ricardo Mones
~
You have the capacity to learn from mistakes. You'll learn a lot
today. /usr/games/fortune
Re: Spliting packages between pkg and pkg-data
Scripsit Henrique de Moraes Holschuh [EMAIL PROTECTED]
1. -data packages should probably recommend their parent packages if they
are useless without the main package. And versioning should be used if
possible (and needed, don't do it just because), but it cannot be too
strict (= ${Source-Version}) between arch all and arch !all packages,
since that breaks bin-NMUs (which is arguably a minor bug in the whole
bin-NMU concept, or in dpkg's lack of a mostly equal operator that also
matches bin-NMUs).
What would be the benefit of a versioned Recommends, rather than an
unversioned one? If the main package itself Depends on the -data with
a tight versioning (which _is_ possible if only debian/rules takes
care to remove any binNMU version when it is being built), then the
only way to _satisfy_ the Recommendation will be to use the matching
version, even if the Recommends itself is unversioned.
4. Also IMHO one should at the very least suggest the main package from the
-data package. This helps the users of non-crappy apt frontends to
track the main package starting from the -data package. Relying on
package naming alone for this is suboptimal at best.
Additionally, make sure that the secondary packages are tagged
special::auto-inst-parts in debtags.
--
Henning MakholmThere is a danger that curious users may
occasionally unplug their fiber connector and look
directly into it to watch the bits go by at 100 Mbps.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: I am still on the keyring. With my old key.
Scripsit Martijn van Oosterhout [EMAIL PROTECTED] My first thought would be to simply create multiple keyrings, one for each keyring maintainer, which are merged on a regular basis. Teaching the archive scripts to look at more than one keyring wouldn't be too hard. That would not solve the most acute problem: That of _removing_ a key quickly if the keyring maintainer who originally added it is temporarily unavailable. -- Henning Makholm Slip den panserraket og læg dig på jorden med ansigtet nedad! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: My IP address seems listed as a spammer address by bugs.debian.org
* Joey Hess ([EMAIL PROTECTED]) [051121 16:34]: The LDAP interface is not production quality enough to be used by anything IMHO. It seems to be down or moved to somewhere else half the time. It should now have a permanent address at bts2ldap.debian.net, so at least the moving around should be part of the history. However, sadly, it's still only project and not product quality. Any help on that would be welcome. Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Conffiles and possible conffiles
Frank Küster [EMAIL PROTECTED] writes: Hi, on the debian-tetex-maint mailing list we often have problems to decide which of the thousands of TeX input files should be treated as configuration files - in principle, each of them can be changed in order to change the behavior of the system. We are currently thinking about a solution were there would be hardly any conffiles[1], but a local admin could put copies of any file he likes into subdirectories of /etc/texmf. This would shadow the dpkg-shipped file in /usr/share/texmf and allow configuration. And of course we would document this. There is one major drawback, however: If a file that has a (changed) copy in /etc/texmf is changed in the deb, the user gets no notification. This is at least annoying - but on the other hand, many users have newer or changed versions in /usr/local/share/texmf or in $HOME/texmf, and they face the same problem. What do others think? Would it be acceptable Policy-wise to handle configuration like this? Regards, Frank I think other packages have the same problem, gconf comes to mind, and they should sit together and work out a common solution. It would be nice to notify the user about changes in the default config and give the choice of a diff or 3 way merge. Maybe this is something that could be added to ucf (e.g. option --modified-file=/etc/texmf/foo) and then present the user with the same options and frontend as with normal config files. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: My IP address seems listed as a spammer address by bugs.debian.org
Blars Blarson wrote: If you can't use one of the program intfaces listed above for some reason, put a 5 second sleep between the completion of one request and sending the next. That spreads the load out and gives others a chance to access the BTS. Done in devscripts 2.9.9. PS: Will we ever stop hosting two critical and demanding services (bts, archive) on the same overloaded machine? -- see shy jo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Uploading amd64 packages
On Mon, Nov 21, 2005, Goswin von Brederlow wrote: There are some implementation details that someone would have to fix first [...] So while theoretically source only uploads would be great practically there are problems. I sure hope patches would be welcome though. Well, if Ubuntu implemented it, it might be wiser to try resyncing with their improvements instead. -- Loïc Minier [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Spliting packages between pkg and pkg-data
On Mon, Nov 21, 2005 at 10:47:18AM -0200, Henrique de Moraes Holschuh wrote: 4. Also IMHO one should at the very least suggest the main package from the -data package. This helps the users of non-crappy apt frontends to track the main package starting from the -data package. Relying on package naming alone for this is suboptimal at best. Enrico Zini proposed to use Enhances: instead which seems more correct than Suggests. Cheers, -- Bill. [EMAIL PROTECTED] Imagine a large red swirl here. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: My IP address seems listed as a spammer address by bugs.debian.org
On Mon, Nov 21, 2005 at 10:35:01AM -0500, Joey Hess wrote: Brian M. Carlson wrote: Additionally, the robots.txt is being violated by bts cache, so perhaps someone should file a bug. bts cache is not a web spider, it only downloads the bugs that you tell it to. It violates the robots.txt much less than eg, wget. wget (in non-recursive behaviour, never following any link) downloads only the URLs you tell it too, so according to the same argument, doesn't violate robots.txt . In recursive mode (following links), wget respects robots.txt (by default). -- Lionel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Conffiles and possible conffiles
Hi all, Goswin von Brederlow [EMAIL PROTECTED] wrote: Frank Küster [EMAIL PROTECTED] writes: We are currently thinking about a solution were there would be hardly any conffiles[1], but a local admin could put copies of any file he likes into subdirectories of /etc/texmf. This would shadow the dpkg-shipped file in /usr/share/texmf and allow configuration. [...] What do others think? Would it be acceptable Policy-wise to handle configuration like this? Regards, Frank I think other packages have the same problem, gconf comes to mind, and they should sit together and work out a common solution. Indeed, it would be nice if there was *one* Debian Way. I'm Cc'ing [EMAIL PROTECTED] to get its maintainer into the discussion - and ucf's because of your second proposal. Who else should be contacted? It would be nice to notify the user about changes in the default config and give the choice of a diff or 3 way merge. Maybe this is something that could be added to ucf (e.g. option --modified-file=/etc/texmf/foo) and then present the user with the same options and frontend as with normal config files. This sounds like a rather long-term thing. But on the other hand, it also seems to me as if it can be applied any time later even if we stop shipping arbitrary files as conffiles now, can't it? Regards, Frank -- Frank Küster Inst. f. Biochemie der Univ. Zürich Debian Developer
Re: Spliting packages between pkg and pkg-data
[Thijs Kinkhorst] If package foo-data is useless when foo is not installed, foo-data should depend on package foo. This follows from policy manual 7.2: The Depends field should be used if the depended-on package is required for the depending package to provide a significant amount of functionality.. Or am I missing something here? I guess it is a philosofical question about the functionality provided by foo-data. If the provided functionality is a set of data usable by other packages, for example package 'foo', then it is providing its functionality without a depend on foo. If it is providing the functionality working program foo, then of course, it need to depend on foo. In my view, foo-data is providing the functionality data for packages needing them, for example package 'foo', and foo provides the functionality working program foo. From this perspective, foo-data isn't useless without foo installed, it is perfectly usable as data for any program capable of reading that data. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Spliting packages between pkg and pkg-data
On Mon, 21 Nov 2005, Goswin von Brederlow wrote: Henrique de Moraes Holschuh [EMAIL PROTECTED] writes: 3. Loose dependencies between -data and main packages *CAN* create breakage on partial upgrades, depending on just how tight the relationship between a particular version of the package and its arch-indep data is. Watch out for this, it is NOT always an easy problem to solve because of bin NMUs. One can provide 'foo-abi-1234' and depend on that. For packages that seldomely change the data format this works fine. For frequent/regular data format changes a Depends: foo-data (= 1.2-3), foo-data ( 1.2-3.1) or ( 1.3) should do the job. I like this one, it is less error-prone than trying to track ABIs when you don't have to do so already for another reason (such as dynamic linking). 4. Also IMHO one should at the very least suggest the main package from the -data package. This helps the users of non-crappy apt frontends to track the main package starting from the -data package. Relying on package naming alone for this is suboptimal at best. Actualy I would love to have the naming policy set in stone and frontends filter for them. There is no reason to list foo-data in the Please don't. I don't want my package management tools dumbed down. The day I have to start second-guessing aptitude is the day I drop it. If it is optional behaviour, then I wouldn't mind it, but I would still tack a recommends or suggests in -data pointing back to the main package. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Spliting packages between pkg and pkg-data
Scripsit Goswin von Brederlow [EMAIL PROTECTED] Actualy I would love to have the naming policy set in stone and frontends filter for them. There is no reason to list foo-data in the package list but only foo. The frontends can do a simple check: if ($PKG depends on $PKG-data) then hide $PKG-data. I think that using debtags (special::auto-inst-parts) is a better way of doing this than trying to cram even more information coding into the package namespace than we already have. -- Henning Makholm The bread says TOAST. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Getting rid of circular dependencies, stage 2
On Fri, Nov 18, 2005 at 10:05:02AM -0800, Steve Langasek wrote: On Fri, Nov 18, 2005 at 06:08:52PM +0100, Bill Allombert wrote: Probably I should do a massive bug report ? Sounds like a good idea to me. Thanks for working on this! I started the bug filling, see the result here: http://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=circular-deps;[EMAIL PROTECTED] Also Robert Lemmen provide now the listing of packages affected per maintainers here: http://debian.semistable.com/unstable_developers.txt I would like to thanks the maintainers for the positive feedback I got (only two reports get summarily closed so far). Though I think we have at least some false-positives to weed out first: * libxtst6 libxtrap6 libxrender1 libxrandr2 libxpm4 libxp6 libxt6 libxmu6 libxi6 libsm6 xlibs Given that I can remove xlibs from my system and not take any of these other libs along, this looks like a false positive (probably as a result of the many or'ed deps on xlibs). I am not sure, there are other possibilities since dpkg will not install extra packages to break a circular dep. However much of the grief come from the | xlibs ( 4.1.0) which is meant to handle upgrade from woody which have a monolithic xlibs, and can probably be removed now. Cheers, -- Bill. [EMAIL PROTECTED] Imagine a large red swirl here. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Spliting packages between pkg and pkg-data
On Mon, Nov 21, 2005 at 04:36:41PM +0100, Thijs Kinkhorst wrote: If package foo-data is useless when foo is not installed, foo-data should depend on package foo. This follows from policy manual 7.2: The Depends field should be used if the depended-on package is required for the depending package to provide a significant amount of functionality.. Or am I missing something here? Data packages does not provide functionnality per se. They provide files. Consider a data package foowm-icons providing icons for a window manager foowm: if foowm is not installed, the data package is 'useless', but in fact you can look up the icon more easily with an image browser than by running the window manager launch random apps and iconify them to see thet icon displayed. So foowm does not provide any more functionality to foowm-icons, it is the other way round. Hence the proposal of Enrico Zini to use Enhances: instead. Anyway I would like to remember you that policy 7.2 say also This declares an absolute dependency. A package will not be configured unless all of the packages listed in its `Depends' field have been correctly configured. Which imply that package with circular dependencies cannot be installed at all. Cheers, -- Bill. [EMAIL PROTECTED] Imagine a large red swirl here. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Spliting packages between pkg and pkg-data
Hi, Petter Reinholdtsen wrote: I guess it is a philosofical question about the functionality provided by foo-data. If the provided functionality is a set of data usable by other packages, for example package 'foo', then it is providing its functionality without a depend on foo. If it is providing the functionality working program foo, then of course, it need to depend on foo. No, it needs to Recommend foo, not Depend on it. Otherwise you end up with a dependency loop. Simon signature.asc Description: OpenPGP digital signature
Re: Spliting packages between pkg and pkg-data
On Mon, 21 Nov 2005, Bill Allombert wrote: On Mon, Nov 21, 2005 at 10:47:18AM -0200, Henrique de Moraes Holschuh wrote: 4. Also IMHO one should at the very least suggest the main package from the -data package. This helps the users of non-crappy apt frontends to track the main package starting from the -data package. Relying on package naming alone for this is suboptimal at best. Enrico Zini proposed to use Enhances: instead which seems more correct than Suggests. What does Enhances do *exactly*? Or is it just for reference purposes and the tools are free to use it as they will (and dpkg/apt itself will just ignore it)? Last time I checked, it was a for reference purposes only thing, so it may not be as functional as a suggests. You can always add both, of course. -- 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: getting unstable lintian linda into stable
Hi Christoph, On Friday, 11 Nov 2005, you wrote: Maybe lintian could detect if if was running on stable when it should be on unstable, and warn the user. I'm not sure how to do this, since there are legitimate uses on stable where you wouldn't want to get the warning. it could parse the changelog entry and try to detect if the upload is for stable-(security|proposed-updates). If not, and APT prefers stable (stolen from reportbug), lintian/linda could give a warning. This requires lintian/linda to run in the same enviroment than the package has been build (ie. a chroot). Greetings Martin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RAW COTTON
plz i need some info about raw cotton iv got to do a project iv been on the internet but nothing plz ill say again i need some info about raw cotton, how its made ect. p.s i need it quiet quick yours sincerly x x x x x
Re: Spliting packages between pkg and pkg-data
On Mon, Nov 21, 2005 at 02:45:06PM -0200, Henrique de Moraes Holschuh wrote: On Mon, 21 Nov 2005, Bill Allombert wrote: Enrico Zini proposed to use Enhances: instead which seems more correct than Suggests. What does Enhances do *exactly*? Or is it just for reference purposes and the tools are free to use it as they will (and dpkg/apt itself will just ignore it)? My hope is that if more people start to use it, then package managers can start building features with it. A first start would probably be a tool that could show reverse-Enhances for a given package. I'll keep that in mind as a thing to play with when coding with libapt-front. Ciao, Enrico -- GPG key: 1024D/797EBFAB 2000-12-05 Enrico Zini [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: master's mail backlog and upgrade time
Six days ago I discovered that one of the Debian system administrators had made a deliberate and highly unusual configuration change which predictably broke mail from or via master to: * me personally * some of the =8 other Debian developers who have accounts on chiark * the Technical Committee No-one had contacted me, or anyone else affected. The exact causes and responsibility for the root problem that the administrator was trying to solve have been discussed extensively in the thread on debian-devel, but in any case immediately I found out about the situation I arranged matters so that master should no longer have any difficulty talking to chiark. I also immediately notified debian-admin of these facts and have not had: * Correction of the broken configuration on master * An apology for the lack of communication or a promise to do better This situation is intolerable and must be rectified forthwith. If the Debian system administrators are too busy to deal with this then I would be happy to help. Ian. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Automated testing - design and interfaces
Anthony Towns writes (Re: Automated testing - design and interfaces): On Thu, Nov 17, 2005 at 06:43:32PM +, Ian Jackson wrote: The source package provides a test metadata file debian/tests/ control. This is a file containing zero or more RFC822-style stanzas, along these lines: Tests: fred bill bongo Restrictions: needs-root breaks-computer This means execute debian/tests/fred, debian/tests/bill, etc., Seems like: debian/tests/bar: #!/bin/sh # Restrictions: needs-root trashes-system # Requires: foo Urgh. I'm really not a fan of those files which mix up different languages. We'll end up with complicated scheme for separating out the test metadata from other stuff appearing in the comments at the top of files (Emacs and vim modes, #! lines, different comment syntaxes in different languages, etc.) Also, we want to be able to share the actual tests - that is, the meat of the work - with non-Debian systems. So we should separate out the metadata (which describes when the test should be run and where it is, and is Debian-specific) from the actual tests (which need not be Debian-specific). Is the Depends: line meant to refer to other Debian packages (and thus be a lower level version of Restrictions:) or is it meant to indiciate test interdependencies? If it's meant to be for debian packages, maybe # Restrictions: deb:xvncviewer might be better. Yes, Depends is semantically much like Restrictions but refers to a Debian package (which must be installed on the test system). However, Depends might have version numbers etc. - it's just like a Depends field. I don't want to try to mix that with the simple syntax of Restrictions. IMO it's better to have two fields if the structure (and hence the syntax) of the information is going to be significantly different, even if there's a certain similarity to the semantics. Note that it's often better to have a single script run many tests, so you probably want to allow tests to pass back some summary information, or include the last ten lines of its output or similar. Something like: foo FAIL: FAILURE: testcase 231 FAILURE: testcase 289 FAILURE: testcase 314 3/512 test cases failed This is no good because we want the test environment to be able to tell which tests failed, so the test cases have to be enumerated in the test metadata file. You do have a point about not necessarily starting a single process for each test. An earlier version of my draft had something like Test: .../filename+ where the + meant to execute filename and it would print 138: PASS 231: FAIL 289: FAIL 314: SKIP: no X11 or some similar standard format. A basic test could be simply running the binary and checking the result status (or other variants of this). Eventually every package would to be changed to include at least one test. These sorts of tests are better done as part of debian/rules, I would've thought -- the advantage of that is that the problems get caught even when users rebuild the package themselves, and you don't need to worry about special test infrastructure like you're talking about for the simple case. You can't check that the binary works _when the .deb is installed_ without installing it. Ideally eventually where possible the upstream regression tests could be massaged so that they test the installed version. Whether this is possible and how best to achieve it has to be decided on a per-package basis. Having Restrictions: package-installed and Restrictions: build-tree Hrm, that's an interesting idea. I really think that concentrating on testing as-installed is going to yield much richer results - that is, more test failures :-). So I want to provide that interface straight away. Also, a `Restriction' isn't right because if the test has neither of those Restrictions then presumably it can do either but how would it know which ? Even integration tests can be represented like this: if one package's tests Depend on the other's, then they are effectively integration tests. The actual tests can live in whichever package is most convenient. Going from build/foo-1.0/debian/tests/x to projects/bar-3.14/debian/tests/y seems difficult. No, I mean that if the tests live (say) in build/foo-1.0/debian/tests/x then build/foo-1.0/debian/tests/control could say Depends: bar which would mean bar would have to be installed, effectively making it an integration test. Anyway, something that can be run with minimal amounts of setup seems most likely to be most useful: so running as part of the build without installing the package, running without anything special installed but the package being tested and a script that parses the control information, stuff that can be run on a user's system without root privs and without trashing the system, etc. My idea is that the test runner will do `something
Re: status of vore?
On Monday 21 November 2005 12:07, Ingo Juergensmann wrote: I could give you an account on a sparc machine with unstable chroot, but that's a non-debian.org machine, so it's mostly usuable for debugging and not for a build of an binary upload. Thanks, but as the main goal is creating a new debian package I fear I will just have to wait for another 'official' sparc machine. Groetjes, Peter -- signature -at- pvaneynd.mailworks.org http://www.livejournal.com/users/pvaneynd/ God, root, what is difference? Pitr | God is more forgiving. Dave Aronson| -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
reactivating my debian developer account
I would like to reactivate my debian developer account. Ive been MIA for a while unfortunately, but have now rearranged my life so I have time to program for fun again. Is there a standard procedure for doing this that someone can point me to? Thanks, Britton Kerin -- Britton Kerin [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: master's mail backlog and upgrade time
Simon Richter [EMAIL PROTECTED] wrote: Andreas Metzler wrote: The real problem with these bounces is not that they fill up the forwarding host's queue but that they are usually unwanted. Think Joe Job. This thread is about email that is obviously not legitimate just looking at the envelope. [...] I missed that piece if information. Thanks for pointing it out. cu andreas -- The 'Galactic Cleaning' policy undertaken by Emperor Zhark is a personal vision of the emperor's, and its inclusion in this work does not constitute tacit approval by the author or the publisher for any such projects, howsoever undertaken.(c) Jasper Ffforde -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
KDE4stable - a proposal
Good morning I hate double made work. But I love debian and I love KDE. The only problem is that Debian stable has an outdated KDE version after some time. The solution is backporting the current KDE version to Debian stable. It's done by different projects (see below) and different projects need a backport of the current KDE version. So why shouldn't we join forces and work together on a backport of KDE for Debian stable (and derivate distributions). My proposal follows now in less and more detail. Short version: -- Lets cooperate with the backport of current KDE. Create an alioth [1] project with a mailinglist, a repository (debian packages and svn) and some FAQs. More details: - Here are some more ideas: - Some releaseplan: - make quickly first packages (together with the Debian KDE/Qt Team and Kubuntu team) (State: unusable) - announce workable packages (State: testable) - declare them stable for productive use (state: usable) (States similar to stable, testing and unstable. This way the user sees the state of the packages at once.) - Provide security support for the packages declared 'usable'. - We restrict on some architectures (i386, amd64, powerpc, ...) - We garantee a smooth migration path to the next stable version of Debian (i.e. the backported KDE version should always be a version less than the version in Debian testing/unstable). - Additional backport of further KDE applications. Future perspective: --- Debian Etch will probably released with KDE 3.5.x and not KDE 4.x. So if we have to infrastructure we could shortly after present a Debian stable etch version with the current KDE. I'm (and surely others too) interested in your opinion and if you like to work with us. And last but not least, here are some information about me: Primary school teacher, student in education and computer sciences. Longstanding Debian user and trying to give something back (e.g. DDTP translations and YaST4Debian [2]). My best skills are not (yet) programming but coordination, documentation and organisation. Why specifically this mailing list (different in each mail)? I choose this list and set the Reply-To: to it because it's the central point of Debian development. This mail is sent to the following mailing lists: - - http://lists.debian.org/debian-devel/ - main Debian development mailing list - http://lists.debian.org/debian-qt-kde/ - mailing list of the Debian KDE/Qt Team - http://lists.debian.org/debian-edu/ - mailing list of the Debian Edu/Skolelinux project - http://lists.dccalliance.org/mailman/listinfo/dcc-devel - development list of the DCC Alliance (with members like Linspire, Knoppix and Progeny) - https://mail.kde.org/mailman/listinfo/kalyxo-devel - development list of the Ekhis/Kalyxo project - http://lists.ubuntu.com/mailman/listinfo/kubuntu-devel - development list of the Kubuntu distribution Reply-To: is set to debian-devel@lists.debian.org Possible next steps: - If there is some possible feedback to this mail I'll request for an alioth project and setup a short FAQ and mailing list. - As the release of KDE 3.5 is imminent we could together start with the packaging work of KDE 3.5 (based on the work Last not: I don't intent to steal some work of any project but I think we could join the forces which would facilitate a lot. I appreciate all the work you all do! I wish you all a good week Mario [1] http://alioth.debian.org [2] http://alioth.debian.org/projects/yast4debian PS: I'm subscribed to every mailing list I'll post this message to. So it's not necessary to CC: me. PPS: Sorry for the unperfect english ;-). -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Getting rid of circular dependencies, stage 2
On Mon, Nov 21, 2005 at 04:01:54PM +0100, Bill Allombert wrote: However much of the grief come from the | xlibs ( 4.1.0) which is meant to handle upgrade from woody which have a monolithic xlibs, and can probably be removed now. It's already been removed in experimental, and is slated to be removed in the next upload of Xorg to unstable, be it 6.8 or 6.9. If this really is an important issue, I can do a 6.8 upload to unstable within 24 hours. - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: removal syncing among official and amd64 archive
On Sat, Nov 19, 2005 at 06:42:15PM +0100, Goswin von Brederlow wrote: [EMAIL PROTECTED]:/org/amd64.debian.net$ madison editex editex |0.0.5-6 |stable | source editex |0.0.5-6 | unstable | source As you can see editex is already removed from etch since Heidi syncs are instantaneous. Ok, so there is some out-of-syncing somewhere else: http://packages.debian.org/cgi-bin/search_packages.pl?keywords=editexsearchon=namessubword=1version=allrelease=all editex is listed as available on unstable only for the amd64 architecture. -- Stefano Zacchiroli -*- Computer Science PhD student @ Uny Bologna, Italy [EMAIL PROTECTED],debian.org,bononia.it} -%- http://www.bononia.it/zack/ If there's any real truth it's that the entire multidimensional infinity of the Universe is almost certainly being run by a bunch of maniacs. -!- signature.asc Description: Digital signature
Re: ITP: pykdeextensions -- Python packages to support KDE applications (scripts)
Hi, On Mon, 2005-11-21 at 12:51 +0100, Fathi Boudra wrote: Those packages (pykdeextensions, libpythonize and kde-guidance) are already in Ubuntu Breezy (Ubuntu and Kubuntu Flavour). If you're interested, you can have a look into those package and push them into Debian. thanks for the advice but i know this because i've done the base packaging with jonathan riddell of these packages :) Bah...Jonathan and his secrets :) I had not made the ITP for debian only ;) so the RFS will follow quickly to push them into debian. Forget what I was writing :) Regards, \sh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: reactivating my debian developer account
Hi, * Britton Kerin [EMAIL PROTECTED] [2005-11-21 20:38]: I would like to reactivate my debian developer account. Ive been MIA for a while unfortunately, but have now rearranged my life so I have time to program for fun again. Is there a standard procedure for doing this that someone can point me to? Yes: http://lists.debian.org/debian-devel-announce/2005/02/msg3.html Point 4. Kind regards Nico Golde -- Nico Golde - JAB: [EMAIL PROTECTED] | GPG: 0x73647CFF http://www.ngolde.de | http://www.muttng.org | http://grml.org Forget about that mouse with 3/4/5 buttons - gimme a keyboard with 103/104/105 keys! pgp0FJ5GHy9CK.pgp Description: PGP signature
Re: Getting rid of circular dependencies, stage 2
On Mon, Nov 21, 2005 at 03:06:49PM -0500, David Nusinow wrote: On Mon, Nov 21, 2005 at 04:01:54PM +0100, Bill Allombert wrote: However much of the grief come from the | xlibs ( 4.1.0) which is meant to handle upgrade from woody which have a monolithic xlibs, and can probably be removed now. It's already been removed in experimental, and is slated to be removed in the next upload of Xorg to unstable, be it 6.8 or 6.9. If this really is an important issue, I can do a 6.8 upload to unstable within 24 hours. It is not. Most probably the only grief it cause is to make the dependency graph so obscure that I cannot make anything out of it: http://debian.semistable.com/dot/xlibs_unstable.png On the other hand there is a circular depends libxi-dev -- libx11-dev. (btw, the last line of the description of libxi-dev have 2 typos, maual and inteat.) Cheers, -- Bill. [EMAIL PROTECTED] Imagine a large red swirl here. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Spliting packages between pkg and pkg-data
On Mon, Nov 21, 2005 at 04:26:34PM +0100, Goswin von Brederlow [EMAIL PROTECTED] was heard to say: Nicolas Boullis [EMAIL PROTECTED] writes: On Sun, Nov 20, 2005 at 12:13:48PM +0100, Bill Allombert wrote: Hello Debian developers, When doing research about circular-deps, I looked at a lot of packages that are split between a binary package and a data package. This is a good thing since this reduce the total siez of the archive, however there are simple rules that should be followed: 3) Keep the files that 'signal' executables in the same package than the executable (e.g. menu file, program manpage). Why? I agree that it menu files and manpages are generally not that large, but what would it break to have them in pkg-data? (I would consider it strange to have such files out of the main pkg package, but it looks policy-compliant as far as I can see...) Nicolas foo depends on foo-data. But foo-data does NOT depend on foo. So an apt-get install foo-data, while being useless, is consistent for dpkg. After that you would end up with a menu entry for foo but no foo binary. Shouldn't menu refuse to create menu entries for foo if the foo package is not installed? At least, I thought that's what ?package(foo): ... meant. Daniel signature.asc Description: Digital signature
Re: Spliting packages between pkg and pkg-data
On Mon, Nov 21, 2005 at 12:35:31PM -0800, Daniel Burrows wrote: On Mon, Nov 21, 2005 at 04:26:34PM +0100, Goswin von Brederlow [EMAIL PROTECTED] was heard to say: Nicolas Boullis [EMAIL PROTECTED] writes: On Sun, Nov 20, 2005 at 12:13:48PM +0100, Bill Allombert wrote: Hello Debian developers, When doing research about circular-deps, I looked at a lot of packages that are split between a binary package and a data package. This is a good thing since this reduce the total siez of the archive, however there are simple rules that should be followed: 3) Keep the files that 'signal' executables in the same package than the executable (e.g. menu file, program manpage). Why? I agree that it menu files and manpages are generally not that large, but what would it break to have them in pkg-data? (I would consider it strange to have such files out of the main pkg package, but it looks policy-compliant as far as I can see...) Nicolas foo depends on foo-data. But foo-data does NOT depend on foo. So an apt-get install foo-data, while being useless, is consistent for dpkg. After that you would end up with a menu entry for foo but no foo binary. Shouldn't menu refuse to create menu entries for foo if the foo package is not installed? At least, I thought that's what ?package(foo): ... It does, provide you don't do ?package(foo-package): of course. Cheers, -- Bill. [EMAIL PROTECTED] Imagine a large red swirl here. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
debian swirl analog clock
Does anyone know of an analog clock built on top of the Debian swirl? Through a configuration error, I discovered the cool XMMS Debian theme, and got to wishing that I had a bit more of a Debian feel to my desktop. I love running an analog clock, and seeing it next to my new XMMS, I couldn't help but wishing that the hands on the clock turned around the Debian swirl. Charles -- It's not toasted It's not dated But look out -- It's imitated Insist on Burma-Shave http://burma-shave.org/jingles/1933/its_not_toasted signature.asc Description: Digital signature
Re: master's mail backlog and upgrade time
Ian Jackson [EMAIL PROTECTED] writes: Six days ago I discovered that one of the Debian system administrators had made a deliberate and highly unusual configuration change which predictably broke mail from or via master to: Err, no. Mail was _already_ bouncing, but after reaching the retry maximum. The change did not change the end result, only when it happened. No-one had contacted me, or anyone else affected. The change was made roughly less than 24 hours before your first post to debian-devel. There wasn't actually all that much time to contact you in. but in any case immediately I found out about the situation I arranged matters so that master should no longer have any difficulty talking to chiark. Err, no you haven't. In [EMAIL PROTECTED] posted on Sat, 19 Nov 2005 15:39:36 +, you've asked chiark users to individually change their config to ensure chiark won't DoS master. Until it's confirmed that all those users have done so, it's not fair to say master will not have any difficulty talking to chiark. And this still relies on per-user config rather than being a global change. Which means the next time a chiark user gets a debian.org account but neglects to perform the necessary incantation, master will once again be DoSed by chiark. I also immediately notified debian-admin of these facts and have not had: Err, no you didn't. You mailed debian-devel, and THREE DAYS LATER mailed debian-admin. That is not immediate. * Correction of the broken configuration on master [EMAIL PROTECTED]:~$ grep chiark /etc/exim4/exim4.conf [EMAIL PROTECTED]:~$ And it's been like that for several days. * An apology for the lack of communication or a promise to do better Speaking of doing better, could you please actually fix chiark? Because it's STILL firewalling master This situation is intolerable and must be rectified forthwith. With all due respect, your attitude is intolerable and should be rectified forthwith. If the Debian system administrators are too busy to deal with this then I would be happy to help. No thanks. -- James -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: I am still on the keyring. With my old key.
On Mon, 21 Nov 2005 09:05:02 +0100, Andreas Schuldei [EMAIL PROTECTED] wrote: * Marc Haber [EMAIL PROTECTED] [2005-11-21 08:55:52]: On Sun, 20 Nov 2005 11:29:19 +0100, Petter Reinholdtsen [EMAIL PROTECTED] wrote: I seriously hope the non-elected people blocking and slowing down several important processes in Debian soon realize that there is a problem and that it might be best for them to solve it by stepping aside or allowing new people to help them with the tasks. I have lost _that_ hope like two years ago. It is not the case that these problems with the non-elected people who keep blocking processes are new. No, they have been there even when I joined the project. i have not given up that hope yet and i invest a considerable amount of time working on this issue as part of my work on the DPL-Team. others there do so, too. If the DPL team is actually addressing that issue, it is not doing so transparently. Hence, to the mere mortal DD; nothing has changed since Branden's electrion, which is a real disappointment. At least to me. 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: Advices for an su transition
On Sun, Nov 20, 2005 at 06:22:16PM -0600, Bill Allombert wrote: Actually looks here: http://merkel.debian.org/~ballombe/ The full data is available on merkel.debian.org in ~ballombe/menu/supackages. Thanks a lot! At least all these maintainer scripts seems OK. I can probably check all the native packages now. Best Regards, -- Nekral -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: BTS down?
Hi, Bastian Venthur schrieb: yesterday I've written two bugreports with reportbug. The bugs have been sent to bugs.debian.org and reportbug said, I'd receive an answer within the next hour. This was like 15h ago and I still did not receive an answer. Maybe this has something to do with #338900 (smtp connection direct to master.debian.org is fails) -- I had master.debian.org in my .reportbugrc too but a few days ago reportbug was not able to send messages to this server anymore, so I changed the smtphost manualy to bugs.debian.org, which seemed to work. But since I did not receive an answer and my reports don't appear in the BTS I wonder whether something went wrong. I never had any problems with reportbug and besides the change of the smtphost I did not touch the configs for a very long time. Can somebody confirm that there is a problem with the BTS? I've got the same setup and the same problem. Still no confirmation from bugs.debian.org. Is there another possibility to report bugs (i.e. a web page) than reportbug? Is my bugreport lost? Thanks, Gregor -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: BTS down?
On Mon, 21 Nov 2005, Gregor Jasny wrote: Bastian Venthur schrieb: Can somebody confirm that there is a problem with the BTS? I've got the same setup and the same problem. Still no confirmation from bugs.debian.org. The BTS is currently receiving mail properly and acting on it properly, as near as I can tell. Is there another possibility to report bugs (i.e. a web page) than reportbug? Is my bugreport lost? Just use reportbug; if necessary, point it directly at bugs.debian.org. If you give me the precise message ID and the time of your message, I may be able to track it down if it ever actually reached spohr. Don Armstrong -- When I was a kid I used to pray every night for a new bicycle. Then I realised that the Lord doesn't work that way so I stole one and asked Him to forgive me. -- Emo Philips. http://www.donarmstrong.com http://rzlab.ucr.edu signature.asc Description: Digital signature
Re: Querying the BTS
On 21:27 Wed 16 Nov 2005, Christoph Haas wrote: A quick test revealed that this interface works. Of course this works, many script serving different services work because of this. What I also do from time to time is fetch one specific bug page and parse it, that also work, but it's hard to make it work properly. -- David Moreno Garza [EMAIL PROTECTED] | http://www.damog.net/ [EMAIL PROTECTED] | GPG: C671257D ¿Y dejaste tu país por ésto? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: I am still on the keyring. With my old key.
Hi Henning, On Mon, Nov 21, 2005 at 02:18:02AM +0100, Henning Makholm wrote: Scripsit Martijn van Oosterhout [EMAIL PROTECTED] push aside? There's no rule that says there can be only one. Yes, replacing someone could become ugly, but providing additional hands can't be considered bad, can it? It can be considered bad from a technical viewpoint - as far as I understand the master copy of the keyring is currently on a medium that is under the keyring maintainer's direct physical control. The obvious way of switching to team maintenance of the keyring would entail keeping the master copy in a central machine - for example on a debian.org box somewhere in a colo. Doing that in a way that does not leave the keyring more vulnerable to surreptitious compromise than some reasonable persons might prefer, requires software support that does not currently exist. If somebody designs and implements (after a suitable architectural review) some software to support distributed keyring maintenance in a secure, auditable way, it is likely that calls for adding more people to the task would be considered more seriously. This is an interesting technical position but one that I think is incorrect. The [EMAIL PROTECTED] is to add, update and remove keys in the keyring. Generally both the add and remove functions should be done after being directed to -- either via a GR or from the Debian Account Maintainers (DAM)s, or in the case of removal once a developer has resigned -- not on their own accord. This leaves the update function, which has a number of components: - update the signature set of existing keys (simple) Poll the various public keyservers to for each key existing on the keyring. - migrate a developer from current to emeritus and vice versa (medium) I would assume that this also occurs upon the instructions of some other entity, either QA, the developer themself, via GR, etc. - replace an existing (compromised, lost) key with a new one (hard) This seem to be the problematic function. This is hard because the solution it isn't just technical (like the first), nor social (like the second) but a combination of them both. One solution might be: - require the developer to generate a new key - require the developer to have _at least_ N number of other, existing developers sign their key - once the developer submits their new key, the keyring-maint can select M of the N signatures from existing developers and ask them to further assure keyring-maint that the developer in question is who they say they are. - once that check passes, update the keyring. I would suggest that M be 2 and N be 3. Anyway, ISTM that removing keys from a keyring is much more important than adding new ones, right? It is also more difficult to implement in a secure distributed way. Anybody can think up a scheme for using gpg signatures to prevent keys from being added without authorisation in the first place. Making sure that a removed key stays removed is a more complex question - particularly if emergency powers-to-remove just get kludged onto the existing system as an afterthought. As I have indicated above, I do not believe the role of keyring-maint is to make *any* decision but to act upon the instructions of other parts of Debian (QA, DAM, tech-ctte, DPL(s), DDs via GR). Ideally the role of keyring-maint can be useful performed by a script but since the set of entities who could instruct the keyring-maint is large it would probably make sense to have a number of humans fronting that script. Cheers, Anand -- `When any government, or any church for that matter, undertakes to say to its subjects, This you may not read, this you must not see, this you are forbidden to know, the end result is tyranny and oppression no matter how holy the motives' -- Robert A Heinlein, If this goes on -- signature.asc Description: Digital signature
Re: mixing different upstream sources in one package
[Nathanael Nerode] Put it in the .diff.gz. If it's too large for that to seem reasonable to you, then you proabably shouldn't put it in your package. :-) Heh, and how large is that? The combined effect of 'configure' and '**/Makefile.in' can look pretty formidable, yet people exist who consider those to be reasonable for a diff.gz. (: signature.asc Description: Digital signature
Re: I am still on the keyring. With my old key.
[Anand Kumria] - require the developer to generate a new key - require the developer to have _at least_ N number of other, existing developers sign their key - once the developer submits their new key, the keyring-maint can select M of the N signatures from existing developers and ask them to further assure keyring-maint that the developer in question is who they say they are. - once that check passes, update the keyring. I would suggest that M be 2 and N be 3. In the 8 years I've been using Debian, I've met, in real life, exactly one developer (and I think 2 former developers). At that rate, were I a developer and needed to revoke/reissue a gpg key, it would take approximately 24 years to accumulate enough signatures to do so. So N=3 sounds high, to me. OTOH, complaints about the keyring maintainer being slow would probably go away, since a 2-month turnaround time is pretty negligible compared to 24 years. (My point isn't really the 24 years, it's that some of us aren't geographically situated to get 3 developer signatures as quickly as you probably think.) signature.asc Description: Digital signature
Re: I am still on the keyring. With my old key.
Andreas Schuldei [EMAIL PROTECTED] writes: i have not given up that hope yet and i invest a considerable amount of time working on this issue as part of my work on the DPL-Team. others there do so, too. I hope this is true. I really do. However, I have no particular evidence that it is true. Maybe you could explain in more detail? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: I am still on the keyring. With my old key.
* Andreas Schuldei: i have not given up that hope yet and i invest a considerable amount of time working on this issue as part of my work on the DPL-Team. others there do so, too. Is this the delegation to teams item on http://wiki.debian.org/DPLTeamCurrentIssues? A rather cryptic reference, IMHO. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted sipsak 0.9.5-1 (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Mon, 21 Nov 2005 16:32:41 +0900 Source: sipsak Binary: sipsak Architecture: source i386 Version: 0.9.5-1 Distribution: unstable Urgency: low Maintainer: ARAKI Yasuhiro [EMAIL PROTECTED] Changed-By: ARAKI Yasuhiro [EMAIL PROTECTED] Description: sipsak - SIP Swiss army knife Changes: sipsak (0.9.5-1) unstable; urgency=low . * New upstream release. Currently disabled 'c-ares'. Because c-ares is not packaged for Debian. Files: ee8dd1702ead53cc05d76fd3037ae87d 585 net optional sipsak_0.9.5-1.dsc 5f6d8df044984061425fdbedea61a64e 156279 net optional sipsak_0.9.5.orig.tar.gz ab11a4cba5605bed0c24ff5c82b17588 7905 net optional sipsak_0.9.5-1.diff.gz 2e42193384c76ba01f379f4d1766a9d5 40600 net optional sipsak_0.9.5-1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDgXiJNOYipi+po4wRAjdnAJ9AAobhfuADiHT64TEuP7UI/G5CnwCfQP8W rmaTXSyjTW+ElcHnAcB2psU= =cJJL -END PGP SIGNATURE- Accepted: sipsak_0.9.5-1.diff.gz to pool/main/s/sipsak/sipsak_0.9.5-1.diff.gz sipsak_0.9.5-1.dsc to pool/main/s/sipsak/sipsak_0.9.5-1.dsc sipsak_0.9.5-1_i386.deb to pool/main/s/sipsak/sipsak_0.9.5-1_i386.deb sipsak_0.9.5.orig.tar.gz to pool/main/s/sipsak/sipsak_0.9.5.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted dhcp 2.0pl5-19.3 (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Mon, 21 Nov 2005 08:54:40 +0100 Source: dhcp Binary: dhcp dhcp-client dhcp-client-udeb dhcp-relay Architecture: source i386 Version: 2.0pl5-19.3 Distribution: unstable Urgency: low Maintainer: Eloy A. Paris [EMAIL PROTECTED] Changed-By: Sam Hocevar (Debian packages) [EMAIL PROTECTED] Description: dhcp - DHCP server for automatic IP address assignment dhcp-client - DHCP Client dhcp-client-udeb - DHCP Client for debian-installer (udeb) dhcp-relay - DHCP Relay Closes: 339595 339637 339711 340106 340109 Changes: dhcp (2.0pl5-19.3) unstable; urgency=low . * Non-maintainer upload. * 203_script_expr.patch: Fixed an error in the patch for #61441. (Closes: #339595, #339637, #340106, #340109). * 116_aligned_structs.diff: New patch fixing alignment issues on Sparc (Closes: #339711). Files: bb1a2d01d1d5c854dfa9382d75b13109 673 net optional dhcp_2.0pl5-19.3.dsc 3b2ab46f0b2886987ede183b21c0fa9d 106463 net optional dhcp_2.0pl5-19.3.diff.gz fbde7f0e0622e8f578a3b50838b5c0a8 109226 net optional dhcp_2.0pl5-19.3_i386.deb 7c73c2b5aa54f4aa631c62f0cc544e43 102804 net optional dhcp-client_2.0pl5-19.3_i386.deb b29f5292d3898b371a123ac314bce6f3 72104 net optional dhcp-relay_2.0pl5-19.3_i386.deb c520ac136a07908d9b8fda2621140227 40624 debian-installer optional dhcp-client-udeb_2.0pl5-19.3_i386.udeb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDgX24fPP1rylJn2ERAm70AKCxErSp+t7i5CiMq9kKz9DVK17YsgCcCl7p 2rpLH/Z/ZJRKW0iyr8Z+piE= =Od6n -END PGP SIGNATURE- Accepted: dhcp-client-udeb_2.0pl5-19.3_i386.udeb to pool/main/d/dhcp/dhcp-client-udeb_2.0pl5-19.3_i386.udeb dhcp-client_2.0pl5-19.3_i386.deb to pool/main/d/dhcp/dhcp-client_2.0pl5-19.3_i386.deb dhcp-relay_2.0pl5-19.3_i386.deb to pool/main/d/dhcp/dhcp-relay_2.0pl5-19.3_i386.deb dhcp_2.0pl5-19.3.diff.gz to pool/main/d/dhcp/dhcp_2.0pl5-19.3.diff.gz dhcp_2.0pl5-19.3.dsc to pool/main/d/dhcp/dhcp_2.0pl5-19.3.dsc dhcp_2.0pl5-19.3_i386.deb to pool/main/d/dhcp/dhcp_2.0pl5-19.3_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted arb 0.0.20050526-6 (source all i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Wed, 9 Nov 2005 13:17:52 +0100 Source: arb Binary: libarb arb arb-doc arb-common Architecture: source all i386 Version: 0.0.20050526-6 Distribution: unstable Urgency: low Maintainer: Andreas Tille [EMAIL PROTECTED] Changed-By: Andreas Tille [EMAIL PROTECTED] Description: arb- [Biology] Integrated package for data handling and analysis arb-common - [Biology] Integrated package for data handling and analysis arb-doc- [Biology] Integrated package for data handling and analysis libarb - [Biology] Integrated package for data handling and analysis Closes: 339861 Changes: arb (0.0.20050526-6) unstable; urgency=low . * Added transfig to depends * Removed Depends: arb from arb-common to avoid circular dependencies Closes: #339861 * Added gcc 4.0.3 to supported compilers in Makefile Files: f0957666dcbc620c44bd8f79b43ba540 720 non-free/science extra arb_0.0.20050526-6.dsc ceb13fcb0da5eefa42d62ba54fd34ca4 22774 non-free/science extra arb_0.0.20050526-6.diff.gz 354af1ace608129de4d141e8e3e5 899264 non-free/science extra arb-common_0.0.20050526-6_all.deb 19ebec52e9068c2317c22b207f81c184 679850 non-free/science extra arb-doc_0.0.20050526-6_all.deb bd6a71cddaa1438735e5ab19c3bfae47 2006488 non-free/science extra arb_0.0.20050526-6_i386.deb adeec4f9729533cf1e1be8249a186c45 847644 non-free/science extra libarb_0.0.20050526-6_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDgXnQYDBbMcCf01oRAqKsAJ92ZWmolN7Y72HQSUfGxYT1uX9EOgCfcRQV KGIUGals3NawVpATKo7wW3k= =wNog -END PGP SIGNATURE- Accepted: arb-common_0.0.20050526-6_all.deb to pool/non-free/a/arb/arb-common_0.0.20050526-6_all.deb arb-doc_0.0.20050526-6_all.deb to pool/non-free/a/arb/arb-doc_0.0.20050526-6_all.deb arb_0.0.20050526-6.diff.gz to pool/non-free/a/arb/arb_0.0.20050526-6.diff.gz arb_0.0.20050526-6.dsc to pool/non-free/a/arb/arb_0.0.20050526-6.dsc arb_0.0.20050526-6_i386.deb to pool/non-free/a/arb/arb_0.0.20050526-6_i386.deb libarb_0.0.20050526-6_i386.deb to pool/non-free/a/arb/libarb_0.0.20050526-6_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted jpegpixi 1.1.1-1 (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Mon, 21 Nov 2005 09:13:20 +0200 Source: jpegpixi Binary: jpegpixi Architecture: source i386 Version: 1.1.1-1 Distribution: unstable Urgency: low Maintainer: Jarno Elonen [EMAIL PROTECTED] Changed-By: Jarno Elonen [EMAIL PROTECTED] Description: jpegpixi - Remove hot spots from JPEG images with minimal quality loss Changes: jpegpixi (1.1.1-1) unstable; urgency=low . * New upstream release (closes #337181) Files: a81718f7760a71b61d3e9b92a68d185f 585 graphics optional jpegpixi_1.1.1-1.dsc c888abdb58ff63d634215d4d5b160d5d 155045 graphics optional jpegpixi_1.1.1.orig.tar.gz 05502f5d4e932eed261f525c483c34db 2670 graphics optional jpegpixi_1.1.1-1.diff.gz a97e2c4baae16cc13356bc7fc1fcd5c5 65464 graphics optional jpegpixi_1.1.1-1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDgYKaX8r5Ai7f5nARAiFdAKCFLVm7MgE5clhT4QTHkOxaLXCbLwCdHbqa TSv49EZz0nLKgeWSXDC5ymU= =s+vu -END PGP SIGNATURE- Accepted: jpegpixi_1.1.1-1.diff.gz to pool/main/j/jpegpixi/jpegpixi_1.1.1-1.diff.gz jpegpixi_1.1.1-1.dsc to pool/main/j/jpegpixi/jpegpixi_1.1.1-1.dsc jpegpixi_1.1.1-1_i386.deb to pool/main/j/jpegpixi/jpegpixi_1.1.1-1_i386.deb jpegpixi_1.1.1.orig.tar.gz to pool/main/j/jpegpixi/jpegpixi_1.1.1.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted freepops 0.0.96-1 (source i386 all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Wed, 16 Nov 2005 22:23:47 +0100 Source: freepops Binary: freepops-doc freepops Architecture: source i386 all Version: 0.0.96-1 Distribution: unstable Urgency: low Maintainer: Enrico Tassi [EMAIL PROTECTED] Changed-By: Enrico Tassi [EMAIL PROTECTED] Description: freepops - POP3 interface to several webmails freepops-doc - freepops user/developer manual Changes: freepops (0.0.96-1) unstable; urgency=low . * new upstram release Files: 0e24e855aa6644092a155508d72f3601 721 mail optional freepops_0.0.96-1.dsc 24b28b109ac71608a4bf7db575c6c4ea 2076723 mail optional freepops_0.0.96.orig.tar.gz f70fc9c42113df95d497dfcbb46fc848 9696 mail optional freepops_0.0.96-1.diff.gz 2792050b743dda6bb5d51a7973448ce9 713596 doc optional freepops-doc_0.0.96-1_all.deb b30e70c072ccedb682a50b0ed885a5d1 297268 mail optional freepops_0.0.96-1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDgYiS1cqbBPLEI7wRArXJAJ4wPGQPnlzGCeABLLDVaPhPgjV8eACgsTAc c7FUbl8jP+RUutJ/qsD17n4= =Ag96 -END PGP SIGNATURE- Accepted: freepops-doc_0.0.96-1_all.deb to pool/main/f/freepops/freepops-doc_0.0.96-1_all.deb freepops_0.0.96-1.diff.gz to pool/main/f/freepops/freepops_0.0.96-1.diff.gz freepops_0.0.96-1.dsc to pool/main/f/freepops/freepops_0.0.96-1.dsc freepops_0.0.96-1_i386.deb to pool/main/f/freepops/freepops_0.0.96-1_i386.deb freepops_0.0.96.orig.tar.gz to pool/main/f/freepops/freepops_0.0.96.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted libhttp-body-perl 0.5-1 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Mon, 21 Nov 2005 10:00:47 +0100 Source: libhttp-body-perl Binary: libhttp-body-perl Architecture: source all Version: 0.5-1 Distribution: unstable Urgency: low Maintainer: Debian Catalyst Maintainers [EMAIL PROTECTED] Changed-By: Krzysztof Krzyzaniak (eloy) [EMAIL PROTECTED] Description: libhttp-body-perl - HTTP Body Parser Changes: libhttp-body-perl (0.5-1) unstable; urgency=low . * New upstream release Files: fcc2f4d7939696857cdd8e2efe01ade6 799 perl optional libhttp-body-perl_0.5-1.dsc 83fe5418ef517962f4f6bbcd282d15d6 8136 perl optional libhttp-body-perl_0.5.orig.tar.gz 41497d6826f461279e45b2aebe0703b0 1984 perl optional libhttp-body-perl_0.5-1.diff.gz bc09fd61b32376b325cc6fccde48e90c 13288 perl optional libhttp-body-perl_0.5-1_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDgY0N+NMfSd6w7DERAiALAJ9r/72gfCxZulvNGZLQtBu1BIyPowCgop15 xY4U2MMKhRVEoRYHDoTBXsA= =2ibx -END PGP SIGNATURE- Accepted: libhttp-body-perl_0.5-1.diff.gz to pool/main/libh/libhttp-body-perl/libhttp-body-perl_0.5-1.diff.gz libhttp-body-perl_0.5-1.dsc to pool/main/libh/libhttp-body-perl/libhttp-body-perl_0.5-1.dsc libhttp-body-perl_0.5-1_all.deb to pool/main/libh/libhttp-body-perl/libhttp-body-perl_0.5-1_all.deb libhttp-body-perl_0.5.orig.tar.gz to pool/main/libh/libhttp-body-perl/libhttp-body-perl_0.5.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted maradns 1.0.35-1 (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Mon, 21 Nov 2005 00:14:34 + Source: maradns Binary: maradns Architecture: source i386 Version: 1.0.35-1 Distribution: unstable Urgency: low Maintainer: Kai Hendry [EMAIL PROTECTED] Changed-By: Kai Hendry [EMAIL PROTECTED] Description: maradns- Simple security-aware Domain Name Service server Changes: maradns (1.0.35-1) unstable; urgency=low . * New upstream release * A minor security update http://marc.10east.com/?l=maradns-listm=113235093021398w=2 Files: de9c1932f843bc5fa5ecc47b1ce170e7 558 net extra maradns_1.0.35-1.dsc 2b20a30df4808d73f7552e91ce1998d6 740969 net extra maradns_1.0.35.orig.tar.gz 12d761d683014ad5bf9ecdf1635af621 13547 net extra maradns_1.0.35-1.diff.gz 126687ac78c51fbbdd84b34d725b2a9e 290944 net extra maradns_1.0.35-1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDgY4nK/juK3+WFWQRAvCZAKCLX4MxPLt6y5f7KMrRkdSrZsWB2QCfdJWu Qwe7LJrCktv0FSUGLaDb/pg= =7d1K -END PGP SIGNATURE- Accepted: maradns_1.0.35-1.diff.gz to pool/main/m/maradns/maradns_1.0.35-1.diff.gz maradns_1.0.35-1.dsc to pool/main/m/maradns/maradns_1.0.35-1.dsc maradns_1.0.35-1_i386.deb to pool/main/m/maradns/maradns_1.0.35-1_i386.deb maradns_1.0.35.orig.tar.gz to pool/main/m/maradns/maradns_1.0.35.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted netkit-ftp 0.17-15 (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Mon, 21 Nov 2005 10:18:15 +0100 Source: netkit-ftp Binary: ftp Architecture: source i386 Version: 0.17-15 Distribution: unstable Urgency: low Maintainer: Alberto Gonzalez Iniesta [EMAIL PROTECTED] Changed-By: Alberto Gonzalez Iniesta [EMAIL PROTECTED] Description: ftp- The FTP client Closes: 340082 Changes: netkit-ftp (0.17-15) unstable; urgency=low . * debian/control: Added Depends: on netbase (Closes: #340082) Files: 0e02b52d1b325d7e8a9e855f87099b2d 617 net standard netkit-ftp_0.17-15.dsc 242ae2fef10b1e576709940af2b1404a 21127 net standard netkit-ftp_0.17-15.diff.gz e8aac3b75e950c9b6758f00b874ad58a 50228 base standard ftp_0.17-15_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDgZGjxRSvjkukAcMRAnSyAJ4+jjfS2vGBAG/++1PqUO3RgXtBYwCeLBsg 0MUX4HR2UhO+EnzYVKgLV/M= =nN/2 -END PGP SIGNATURE- Accepted: ftp_0.17-15_i386.deb to pool/main/n/netkit-ftp/ftp_0.17-15_i386.deb netkit-ftp_0.17-15.diff.gz to pool/main/n/netkit-ftp/netkit-ftp_0.17-15.diff.gz netkit-ftp_0.17-15.dsc to pool/main/n/netkit-ftp/netkit-ftp_0.17-15.dsc -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted octave2.1 2.1.72-4 (source all i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Sun, 20 Nov 2005 18:46:56 +0100 Source: octave2.1 Binary: octave2.1-htmldoc octave octave2.1-info octave2.1-emacsen octave2.1 octave2.1-headers octave2.1-doc Architecture: source all i386 Version: 2.1.72-4 Distribution: unstable Urgency: low Maintainer: Debian Octave Group [EMAIL PROTECTED] Changed-By: Rafael Laboissiere [EMAIL PROTECTED] Description: octave - GNU Octave language for numerical computations (2.1 branch) octave2.1 - GNU Octave language for numerical computations (2.1 branch) octave2.1-doc - PDF documentation on the GNU Octave language (2.1 branch) octave2.1-emacsen - Emacs support for the GNU Octave language (2.1 branch) octave2.1-headers - header files for the GNU Octave language (2.1 branch) octave2.1-htmldoc - HTML documentation on the GNU Octave language (2.1 branch) octave2.1-info - GNU Info documentation on the GNU Octave language (2.1 branch) Closes: 339959 Changes: octave2.1 (2.1.72-4) unstable; urgency=low . +++ Changes by Rafael Laboissiere . * debian/in/PACKAGE-info.prerm: Remove alternatives to the info files (closes: #339959) Files: 4e49fd0aeecff87f7a82a6b29b0f4a4e 1068 math optional octave2.1_2.1.72-4.dsc 5eb32a8e79809e38a92610079709b23d 35029 math optional octave2.1_2.1.72-4.diff.gz 0d1db7bb9e0c0e30dc628d715e825eac 5326022 math optional octave2.1_2.1.72-4_i386.deb 99525dc62f793c76be172d01db542102 267190 math optional octave2.1-headers_2.1.72-4_i386.deb 156ca98d3076241b5d3ea780a653140a 1775096 doc optional octave2.1-doc_2.1.72-4_all.deb 76c89005ef0342f5715700ca64ecbd3d 386778 math optional octave2.1-htmldoc_2.1.72-4_all.deb 060ac82280952e4ecaf630c79c4f3b00 71288 math optional octave2.1-emacsen_2.1.72-4_all.deb ebbc7da451405542968b277909b7d467 304942 math optional octave2.1-info_2.1.72-4_all.deb 0ae628c8532d88defb53ccc7d7ff2c2b 48490 math optional octave_2.1.72-4_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFDgbXAk3oga0pdcv4RAsxgAJ4vLE69qIH+imT4TTDaRs83Ne9FkwCglDkU X+S4hleCKydugmJQBNtUoSs= =5jl4 -END PGP SIGNATURE- Accepted: octave2.1-doc_2.1.72-4_all.deb to pool/main/o/octave2.1/octave2.1-doc_2.1.72-4_all.deb octave2.1-emacsen_2.1.72-4_all.deb to pool/main/o/octave2.1/octave2.1-emacsen_2.1.72-4_all.deb octave2.1-headers_2.1.72-4_i386.deb to pool/main/o/octave2.1/octave2.1-headers_2.1.72-4_i386.deb octave2.1-htmldoc_2.1.72-4_all.deb to pool/main/o/octave2.1/octave2.1-htmldoc_2.1.72-4_all.deb octave2.1-info_2.1.72-4_all.deb to pool/main/o/octave2.1/octave2.1-info_2.1.72-4_all.deb octave2.1_2.1.72-4.diff.gz to pool/main/o/octave2.1/octave2.1_2.1.72-4.diff.gz octave2.1_2.1.72-4.dsc to pool/main/o/octave2.1/octave2.1_2.1.72-4.dsc octave2.1_2.1.72-4_i386.deb to pool/main/o/octave2.1/octave2.1_2.1.72-4_i386.deb octave_2.1.72-4_all.deb to pool/main/o/octave2.1/octave_2.1.72-4_all.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted dbus 0.50-3 (source all powerpc)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Mon, 21 Nov 2005 11:17:57 +0100 Source: dbus Binary: libdbus-1-cil libdbus-glib-1-dev dbus-1-utils python2.4-dbus libdbus-qt-1-1c2 monodoc-dbus-1-manual dbus-1-doc dbus libdbus-1-dev libdbus-1-1 libdbus-qt-1-dev libdbus-glib-1-1 Architecture: source powerpc all Version: 0.50-3 Distribution: experimental Urgency: low Maintainer: D-Bus Maintenance Team [EMAIL PROTECTED] Changed-By: Sjoerd Simons [EMAIL PROTECTED] Description: dbus - simple interprocess messaging system dbus-1-doc - simple interprocess messaging system (documentation) dbus-1-utils - simple interprocess messaging system (utilities) libdbus-1-1 - simple interprocess messaging system libdbus-1-cil - CLI binding for D-BUS interprocess messaging system libdbus-1-dev - simple interprocess messaging system (development headers) libdbus-glib-1-1 - simple interprocess messaging system (GLib-based shared library) libdbus-glib-1-dev - simple interprocess messaging system (GLib interface) libdbus-qt-1-1c2 - simple interprocess messaging system (Qt-based shared library) libdbus-qt-1-dev - simple interprocess messaging system (Qt interface) monodoc-dbus-1-manual - compiled XML documentation for the D-BUS CLI bindings python2.4-dbus - simple interprocess messaging system (Python interface) Changes: dbus (0.50-3) experimental; urgency=low . * Also move dbus-launch and dbus-send manpages to the dbus package * debian/dbus.init + Make force-reload an alias of reload instead of restart Files: 6a7a0b40b90e432d5113bb7d290748fe 1240 devel optional dbus_0.50-3.dsc 1a8c605bbf507a836e31744ecf5fd969 18538 devel optional dbus_0.50-3.diff.gz 5ca915d0d4380cb6b59c74f3ed09b7b4 1593950 doc optional dbus-1-doc_0.50-3_all.deb ed9c8be6d1a05802af7d57078285767b 291174 devel optional dbus_0.50-3_powerpc.deb bfee2052d750dc6a8d6d5e25bd690d95 221020 devel optional libdbus-1-1_0.50-3_powerpc.deb 048c8450cbae1c4d235f003b7ef4dc3c 176942 libs optional libdbus-glib-1-1_0.50-3_powerpc.deb 92db3af186a6dbda091b5924d303d0ec 157854 utils optional dbus-1-utils_0.50-3_powerpc.deb 837178f940c1d874d726939079513b6b 284418 libdevel optional libdbus-1-dev_0.50-3_powerpc.deb 40736340d71927d2925cdb6de497910d 226130 libdevel optional libdbus-glib-1-dev_0.50-3_powerpc.deb f71fac7a89566e433dd8368e2f34fcb2 163274 libdevel optional libdbus-qt-1-dev_0.50-3_powerpc.deb 6794ad4d5e3af8083410585b5a6ab14e 158220 libs optional libdbus-qt-1-1c2_0.50-3_powerpc.deb 84b0f72d80d8a88a3b7e95bf5f800212 234342 python optional python2.4-dbus_0.50-3_powerpc.deb 3399f6c9b9b1d261ce3f527f75b22aa0 171316 libs optional libdbus-1-cil_0.50-3_powerpc.deb 9e2dbbf356612e00cdce1c7b1bcaa3cb 164248 doc optional monodoc-dbus-1-manual_0.50-3_powerpc.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDgb5sgTd+SodosdIRAttKAKDgU7uDj66OcGcQ5JeqC5O2GV05OgCg6TTg neY+Lkoq8qVTXjs73b1/TUE= =L1fS -END PGP SIGNATURE- Accepted: dbus-1-doc_0.50-3_all.deb to pool/main/d/dbus/dbus-1-doc_0.50-3_all.deb dbus-1-utils_0.50-3_powerpc.deb to pool/main/d/dbus/dbus-1-utils_0.50-3_powerpc.deb dbus_0.50-3.diff.gz to pool/main/d/dbus/dbus_0.50-3.diff.gz dbus_0.50-3.dsc to pool/main/d/dbus/dbus_0.50-3.dsc dbus_0.50-3_powerpc.deb to pool/main/d/dbus/dbus_0.50-3_powerpc.deb libdbus-1-1_0.50-3_powerpc.deb to pool/main/d/dbus/libdbus-1-1_0.50-3_powerpc.deb libdbus-1-cil_0.50-3_powerpc.deb to pool/main/d/dbus/libdbus-1-cil_0.50-3_powerpc.deb libdbus-1-dev_0.50-3_powerpc.deb to pool/main/d/dbus/libdbus-1-dev_0.50-3_powerpc.deb libdbus-glib-1-1_0.50-3_powerpc.deb to pool/main/d/dbus/libdbus-glib-1-1_0.50-3_powerpc.deb libdbus-glib-1-dev_0.50-3_powerpc.deb to pool/main/d/dbus/libdbus-glib-1-dev_0.50-3_powerpc.deb libdbus-qt-1-1c2_0.50-3_powerpc.deb to pool/main/d/dbus/libdbus-qt-1-1c2_0.50-3_powerpc.deb libdbus-qt-1-dev_0.50-3_powerpc.deb to pool/main/d/dbus/libdbus-qt-1-dev_0.50-3_powerpc.deb monodoc-dbus-1-manual_0.50-3_powerpc.deb to pool/main/d/dbus/monodoc-dbus-1-manual_0.50-3_powerpc.deb python2.4-dbus_0.50-3_powerpc.deb to pool/main/d/dbus/python2.4-dbus_0.50-3_powerpc.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted riece 1.0.8-2 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Mon, 21 Nov 2005 20:27:07 +0900 Source: riece Binary: riece-async riece-rdcc riece riece-hangman riece-lsdb riece-ndcc riece-google riece-xface riece-kakasi Architecture: source all Version: 1.0.8-2 Distribution: unstable Urgency: low Maintainer: OHASHI Akira [EMAIL PROTECTED] Changed-By: OHASHI Akira [EMAIL PROTECTED] Description: riece - an IRC client for Emacs riece-async - connect to IRC server via asynchronous proxy for riece riece-google - Search keywords by Google for riece riece-hangman - Interface to hangman for riece riece-kakasi - convert Japanese to roman string by kakasi for riece riece-lsdb - interface to LSDB for riece riece-ndcc - DCC add-on for riece implemented by emacs lisp riece-rdcc - DCC add-on for riece implemented by ruby riece-xface - display X-Face in user list buffer for riece Closes: 300883 303104 313256 317780 328900 332084 Changes: riece (1.0.8-2) unstable; urgency=low . * control (Standards-Version): Increased to 3.6.2. * control (riece/Build-Depends-Indep): Use `emacsen' instead of `xemacs21'. (closes: #300883) (riece/Depends): Ditto. (riece/Depends): Depends debconf-2.0. (closes: #332084) * control (riece-ndcc/Depends): Depends emacs-snapshot. (closes: #328900) * riece-ndcc.emacsen-install: Support emacs-snapshot. * po/vi.po: Initial Vietnamese translation. (closes: #317780) * po/cs.po: Follow the version of 1.0.8. (closes: #313256) * po/fr.po: Ditto. (closes: #303104) Files: 02e07302b9f355616f0aab80ef931307 718 net optional riece_1.0.8-2.dsc b5275f27069399ebc928f0a3ecdb5e74 101801 net optional riece_1.0.8-2.diff.gz 35dda14915234f16a779f40464fa5eeb 175758 net optional riece_1.0.8-2_all.deb dbc2e94a27b8537ad22712366c276a89 6526 net optional riece-rdcc_1.0.8-2_all.deb 614e1549c5b328a37b5118a4268cad58 6068 net optional riece-ndcc_1.0.8-2_all.deb 236a5497c707c85730c42c9d24ec344e 6102 net optional riece-async_1.0.8-2_all.deb 74383661a02a59a31d1e14278633977e 6016 net optional riece-lsdb_1.0.8-2_all.deb 23051e4fb90378d617276616a48d7451 6030 net optional riece-xface_1.0.8-2_all.deb 8c26ec9d93d11e6534b3a2726ea24916 6040 net optional riece-hangman_1.0.8-2_all.deb 1efb4944f0ce28b87af74dab648ab47c 6022 net optional riece-kakasi_1.0.8-2_all.deb ecefd6c5afe010a3af95286720cec92e 6070 net optional riece-google_1.0.8-2_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDgcaB+pahSABNprQRAricAJ4zSCzNbVZPuBCjS+/GaJPFP4+QFQCdFRvZ 6IeJlCA1BeAp55wyBWRDBfM= =TcvD -END PGP SIGNATURE- Accepted: riece-async_1.0.8-2_all.deb to pool/main/r/riece/riece-async_1.0.8-2_all.deb riece-google_1.0.8-2_all.deb to pool/main/r/riece/riece-google_1.0.8-2_all.deb riece-hangman_1.0.8-2_all.deb to pool/main/r/riece/riece-hangman_1.0.8-2_all.deb riece-kakasi_1.0.8-2_all.deb to pool/main/r/riece/riece-kakasi_1.0.8-2_all.deb riece-lsdb_1.0.8-2_all.deb to pool/main/r/riece/riece-lsdb_1.0.8-2_all.deb riece-ndcc_1.0.8-2_all.deb to pool/main/r/riece/riece-ndcc_1.0.8-2_all.deb riece-rdcc_1.0.8-2_all.deb to pool/main/r/riece/riece-rdcc_1.0.8-2_all.deb riece-xface_1.0.8-2_all.deb to pool/main/r/riece/riece-xface_1.0.8-2_all.deb riece_1.0.8-2.diff.gz to pool/main/r/riece/riece_1.0.8-2.diff.gz riece_1.0.8-2.dsc to pool/main/r/riece/riece_1.0.8-2.dsc riece_1.0.8-2_all.deb to pool/main/r/riece/riece_1.0.8-2_all.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted nevow 0.6.0-2 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Mon, 21 Nov 2005 14:36:54 +0200 Source: nevow Binary: python2.3-nevow python-nevow python2.4-nevow Architecture: source all Version: 0.6.0-2 Distribution: unstable Urgency: low Maintainer: Tommi Virtanen [EMAIL PROTECTED] Changed-By: Tommi Virtanen [EMAIL PROTECTED] Description: python-nevow - Web application templating system for Python and Twisted python2.3-nevow - Web application templating system for Python and Twisted python2.4-nevow - Web application templating system for Python and Twisted Closes: 340052 Changes: nevow (0.6.0-2) unstable; urgency=low . * Fix build-depends, make sure to run the clean build as the _last_ step. Grr. (Closes: #340052) Files: 9835550eec24c522c0ede7af3dd3b1fa 802 devel extra nevow_0.6.0-2.dsc 084a5e6b46a517558d70cb615875bdcf 1952 devel extra nevow_0.6.0-2.diff.gz 907a84b048cfcdc8f2e11078e66a94ff 12916 devel extra python-nevow_0.6.0-2_all.deb d832aafc1ac140b09ba93415ed79bbb6 395734 devel extra python2.3-nevow_0.6.0-2_all.deb 54f58c236bf186518a6cc0d6cc038880 395684 devel extra python2.4-nevow_0.6.0-2_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iQCVAwUBQ4HGHYAGLnzk1H7BAQI4WAQAu6u61OYivarGfoAGfk8bgySUgDvcstGo VLqhUbWnzcjZGAT918Xpll0R+SL4UR2DFdWSvrVaCNbdlEg2jk+PfSKmC/PjRz1B t2VcF7De/jCoZ0HzZ0Ka6yb8B8aDmvAS1a6dAKMPNnfhLm1WE2A1dhL0/JvW6ASZ cRPfAoqA5yU= =5PG5 -END PGP SIGNATURE- Accepted: nevow_0.6.0-2.diff.gz to pool/main/n/nevow/nevow_0.6.0-2.diff.gz nevow_0.6.0-2.dsc to pool/main/n/nevow/nevow_0.6.0-2.dsc python-nevow_0.6.0-2_all.deb to pool/main/n/nevow/python-nevow_0.6.0-2_all.deb python2.3-nevow_0.6.0-2_all.deb to pool/main/n/nevow/python2.3-nevow_0.6.0-2_all.deb python2.4-nevow_0.6.0-2_all.deb to pool/main/n/nevow/python2.4-nevow_0.6.0-2_all.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted linda 0.3.17 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Mon, 21 Nov 2005 22:47:38 +1100 Source: linda Binary: linda Architecture: source all Version: 0.3.17 Distribution: unstable Urgency: low Maintainer: Steve Kowalik [EMAIL PROTECTED] Changed-By: Steve Kowalik [EMAIL PROTECTED] Description: linda - Debian package checker, not unlike lintian Closes: 318561 318578 318919 319426 319746 321775 322245 322289 324674 325591 326166 327057 332746 333514 336473 337627 337893 338848 338850 339812 340032 Changes: linda (0.3.17) unstable; urgency=low . * Linda: - Spit out running as root error to stderr. - Switch to using gettext.install, as well as moving the gettext initialisation into the modules. (Closes: #318561, #318578, #340032) (thanks, Joe Wreschnig) - As a consequence, remove debugging from mygettext, and kill ourselves with exit status 5 if we can't find a .mo file on startup. - Document the change in meaning for exit status 5. - If we can't load modules, don't print out translated messages, as they are printed far too early for us to have correct charset information. - Depend on dpkg-dev. (Closes: #324674) * Collector: - If file dies, don't kill ourselves in sympathy. (Closes: #338850) * Funcs: - Rewrite run_external_cmd to use os.popen, so we can ignore stderr. (Closes: #336473) - If we fail to run a command, dprint out the problem. * Libchecks: - Rewrite transliterate, and a type of udeb should return udeb, not binary. (Closes: #319746) * Manual Page: - Suck COMPARE WITH into SEE ALSO, and add dh_make(1) and debuild(1). (Closes: #322289) * Menu Parser: - Replace '\n' and '\' with ' '. (Closes: #325591, #326166) * Output: - Don't exit 1 if we only find warnings. (Closes: #337893) * Overrides: - Don't die a horrible death if we can't parse overrides. - Don't die if in-tarball overrides can't be parsed. (Closes: #339812) * Unpacking: - Don't die when we can't parse a .dsc. - Don't always try and mkdir the new directory, check that it doesn't exist first. (Closes: #338848) * BinaryCheck: - Consider files which are in a path that contains debug are meant for debugging. (Closes: #332746) * ControlCheck: - Remove package-b-d-on-autostar. (Closes: #327057) - Complain about a missing Section header in the first stanza of a source control file. (Closes: #322245) * DebhelperCheck: - Match python([0-9][0-9])?(-dev)?, not just python and python-dev. (Closes: #333514) * DocumentationCheck: - Only split off 1-8 for manual pages, not 0-9. (Closes: #319426) * LibraryCheck: - Deal with libdir's that end with a /. (Closes: #337627) * MenuCheck: - Correct typo in command-not-quoted. (Closes: #318919) * TruetypefontCheck: - New Check, thanks to Peter De Wachter. (Closes: #321775) * UDebBinaryCheck: - Correct the backward test for usr-doc-in-udeb. * UDebControlCheck: - Correct typo in section-not-di. Files: 1f32e27ac380d47e7dc8d4e3d4fa4a34 537 devel optional linda_0.3.17.dsc 6f3779a48c25c00cdfe898040a93183a 697747 devel optional linda_0.3.17.tar.gz 91d15e2473b0c5099e8c6d7f8791f1fd 204312 devel optional linda_0.3.17_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFDgcXPCfB0CMh//C8RAhICAJ9otoBtopkVezblGBpd5n19W1lh4ACeJ+Ki ZQ+yzinqFs6PRRMs2+Ke/uk= =toDa -END PGP SIGNATURE- Accepted: linda_0.3.17.dsc to pool/main/l/linda/linda_0.3.17.dsc linda_0.3.17.tar.gz to pool/main/l/linda/linda_0.3.17.tar.gz linda_0.3.17_all.deb to pool/main/l/linda/linda_0.3.17_all.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted foo2zjs 20051113-1 (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Fri, 18 Nov 2005 18:40:40 +0100 Source: foo2zjs Binary: foo2zjs Architecture: source i386 Version: 20051113-1 Distribution: unstable Urgency: low Maintainer: Steffen Joeris [EMAIL PROTECTED] Changed-By: Steffen Joeris [EMAIL PROTECTED] Description: foo2zjs- Support for printing to ZjStream-based printers Closes: 279829 279830 294813 339761 Changes: foo2zjs (20051113-1) unstable; urgency=low . * New Maintainer and Co-Maintainer (Closes: #294813) * New upstream release (Closes: #339761) * Added new clean rules because of new version * bumped standard version * cleaned up the debian/control * provide the full source from the author (Closes: #279830, #279829) * wrote all authors to debian/copyright * reformat the manpages to make the package completely lintian clean * upload sponsored by Petter Reinholdtsen Files: 31fed54a4f53dd4df489ba0dc379115b 658 text optional foo2zjs_20051113-1.dsc 4bb9bff3a89cff0b5b5765f09002041d 1048435 text optional foo2zjs_20051113.orig.tar.gz 3287abaf895af66238efa1dbc16b52b2 10752 text optional foo2zjs_20051113-1.diff.gz 7e8c8614e2de10ebaf422af5dc41856f 911106 text optional foo2zjs_20051113-1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDgcza20zMSyow1ykRAlvJAKDhpJG+Evq2KvgWoRzUj14Ot2O9xACcC5Fn soEARZi6PpVMk0SX/L0TjvI= =jjHM -END PGP SIGNATURE- Accepted: foo2zjs_20051113-1.diff.gz to pool/main/f/foo2zjs/foo2zjs_20051113-1.diff.gz foo2zjs_20051113-1.dsc to pool/main/f/foo2zjs/foo2zjs_20051113-1.dsc foo2zjs_20051113-1_i386.deb to pool/main/f/foo2zjs/foo2zjs_20051113-1_i386.deb foo2zjs_20051113.orig.tar.gz to pool/main/f/foo2zjs/foo2zjs_20051113.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted upgrade-system 0.9.7 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Mon, 21 Nov 2005 13:54:18 +0200 Source: upgrade-system Binary: upgrade-system Architecture: source all Version: 0.9.7 Distribution: unstable Urgency: low Maintainer: Martin-Ãric Racine [EMAIL PROTECTED] Changed-By: Martin-Ãric Racine [EMAIL PROTECTED] Description: upgrade-system - Debian system upgrader from Konflux Closes: 00 Changes: upgrade-system (0.9.7) unstable; urgency=low . * Added missing IF statements to removal scripts (Closes: #00). Thanks to Lars Wirzenius for pointing this out. Files: 78aa5a6e322186ae550e7ceadafeb173 534 admin optional upgrade-system_0.9.7.dsc f27541995dfbe5761e93b4959120c099 7462 admin optional upgrade-system_0.9.7.tar.gz cb47ea0ed7c32c0597fcc189bbdedfda 9522 admin optional upgrade-system_0.9.7_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDgdDVy2+jQOcHWlQRAsGbAKCvvlIsGr5lZ2M5MlwIgs+ns/ZKxACfVT+i Vs93Nig4FJKqf17yY5n/74E= =PeAo -END PGP SIGNATURE- Accepted: upgrade-system_0.9.7.dsc to pool/main/u/upgrade-system/upgrade-system_0.9.7.dsc upgrade-system_0.9.7.tar.gz to pool/main/u/upgrade-system/upgrade-system_0.9.7.tar.gz upgrade-system_0.9.7_all.deb to pool/main/u/upgrade-system/upgrade-system_0.9.7_all.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted initz 0.0.11+20030603cvs-9 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Mon, 21 Nov 2005 22:21:40 +0900 Source: initz Binary: initz Architecture: source all Version: 0.0.11+20030603cvs-9 Distribution: unstable Urgency: low Maintainer: OHASHI Akira [EMAIL PROTECTED] Changed-By: OHASHI Akira [EMAIL PROTECTED] Description: initz - Handles the switching of various initialization files of emacsen Closes: 311948 315212 331525 331858 Changes: initz (0.0.11+20030603cvs-9) unstable; urgency=low . * control (Standards-Version): Increased to 3.6.2. * control (initz/Depends): Use `emacsen' instead of `xemacs21'. (initz/Depends): Depends debconf-2.0. (closes: #331858) * emacsen-startup: Support emacs-snapshot. * po/cs.po: Initial Czech translation. (closes: #315212) * po/sv.po: Initial Swedish translation. (closes: #331525) * po/vi.po: Initial Vietnamese translation. (closes: #311948) Files: 62a53774d519baaec0cf8a65590e253f 595 editors optional initz_0.0.11+20030603cvs-9.dsc 23819d7a442a70198950f46ba693d663 6631 editors optional initz_0.0.11+20030603cvs-9.diff.gz d0f56bc62cfaaa67362d106f9911d319 24080 editors optional initz_0.0.11+20030603cvs-9_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDgc7s+pahSABNprQRAtZ4AJ4os70/PekNbhRBIKrxpWYQx5VPtgCcCzyF j62fudZQgStRZjywgGYbgX0= =86Me -END PGP SIGNATURE- Accepted: initz_0.0.11+20030603cvs-9.diff.gz to pool/main/i/initz/initz_0.0.11+20030603cvs-9.diff.gz initz_0.0.11+20030603cvs-9.dsc to pool/main/i/initz/initz_0.0.11+20030603cvs-9.dsc initz_0.0.11+20030603cvs-9_all.deb to pool/main/i/initz/initz_0.0.11+20030603cvs-9_all.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted octave2.9 2.9.4-5 (source i386 all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Mon, 21 Nov 2005 13:01:24 +0100 Source: octave2.9 Binary: octave2.9-headers octave2.9-info octave2.9-htmldoc octave2.9 octave2.9-emacsen octave2.9-doc Architecture: source i386 all Version: 2.9.4-5 Distribution: unstable Urgency: low Maintainer: Debian Octave Group [EMAIL PROTECTED] Changed-By: Rafael Laboissiere [EMAIL PROTECTED] Description: octave2.9 - GNU Octave language for numerical computations (2.9 branch) octave2.9-doc - PDF documentation on the GNU Octave language (2.9 branch) octave2.9-emacsen - Emacs support for the GNU Octave language (2.9 branch) octave2.9-headers - header files for the GNU Octave language (2.9 branch) octave2.9-htmldoc - HTML documentation on the GNU Octave language (2.9 branch) octave2.9-info - GNU Info documentation on the GNU Octave language (2.9 branch) Closes: 339964 Changes: octave2.9 (2.9.4-5) unstable; urgency=low . +++ Changes by Rafael Laboissiere . * debian/in/PACKAGE-info.prerm: Remove alternatives to the info files (closes: #339964) * debian/rules (clean): Remove file examples/octave.desktop, which should be removed by make distcleamn, but is not Files: e846f479f61829d982316716910129af 1089 math optional octave2.9_2.9.4-5.dsc 917a2180d98d92f7051b3896151d8c82 35025 math optional octave2.9_2.9.4-5.diff.gz d1a9c113d6af598352d4757320e92482 6656376 math optional octave2.9_2.9.4-5_i386.deb ac1bf01d7f7f407b74daf04707581a05 319420 math optional octave2.9-headers_2.9.4-5_i386.deb c43c51004fba1a5f7e7898e0a742e8c1 1873970 doc optional octave2.9-doc_2.9.4-5_all.deb c5e9242f16157445d338ba99bda75ffb 401980 math optional octave2.9-htmldoc_2.9.4-5_all.deb 6f25ab0dfd50fd05b3ee07aed4b38bab 74246 math optional octave2.9-emacsen_2.9.4-5_all.deb 9162e4dcfb4ee1dc40b49ed061753c31 331240 math optional octave2.9-info_2.9.4-5_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFDgdVik3oga0pdcv4RAgi1AJ9QbyMN+I24jmEAmqX9UnHGlxrfmQCfTPqy cOptZYqbVKARJLsW8YvWmAU= =wbUZ -END PGP SIGNATURE- Accepted: octave2.9-doc_2.9.4-5_all.deb to pool/main/o/octave2.9/octave2.9-doc_2.9.4-5_all.deb octave2.9-emacsen_2.9.4-5_all.deb to pool/main/o/octave2.9/octave2.9-emacsen_2.9.4-5_all.deb octave2.9-headers_2.9.4-5_i386.deb to pool/main/o/octave2.9/octave2.9-headers_2.9.4-5_i386.deb octave2.9-htmldoc_2.9.4-5_all.deb to pool/main/o/octave2.9/octave2.9-htmldoc_2.9.4-5_all.deb octave2.9-info_2.9.4-5_all.deb to pool/main/o/octave2.9/octave2.9-info_2.9.4-5_all.deb octave2.9_2.9.4-5.diff.gz to pool/main/o/octave2.9/octave2.9_2.9.4-5.diff.gz octave2.9_2.9.4-5.dsc to pool/main/o/octave2.9/octave2.9_2.9.4-5.dsc octave2.9_2.9.4-5_i386.deb to pool/main/o/octave2.9/octave2.9_2.9.4-5_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted libcatalyst-modules-perl 0.04 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Mon, 21 Nov 2005 14:45:06 +0100 Source: libcatalyst-modules-perl Binary: libcatalyst-modules-perl Architecture: source all Version: 0.04 Distribution: unstable Urgency: low Maintainer: Debian Catalyst Maintainers [EMAIL PROTECTED] Changed-By: Krzysztof Krzyzaniak (eloy) [EMAIL PROTECTED] Description: libcatalyst-modules-perl - Modules for Catalyst Changes: libcatalyst-modules-perl (0.04) unstable; urgency=low . * Added Catalyst::Plugin::Prototype * Catalyst::Model::CDBI::CRUD updated to 0.04 Files: 8783dbc6259f31c05d37ad3b313ed70a 1056 perl optional libcatalyst-modules-perl_0.04.dsc af41ddf8ebc597a34e620b4a31a4cd63 14207 perl optional libcatalyst-modules-perl_0.04.tar.gz 1194b8411cb658260e63f71ff19e86cd 20770 perl optional libcatalyst-modules-perl_0.04_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDgdO2+NMfSd6w7DERAsE+AJ4qNJDFP6tOltcut3xTebLnJYx6cACgi7nn UGWE1tJFI4+qSKfafjD61es= =x9Jo -END PGP SIGNATURE- Accepted: libcatalyst-modules-perl_0.04.dsc to pool/main/libc/libcatalyst-modules-perl/libcatalyst-modules-perl_0.04.dsc libcatalyst-modules-perl_0.04.tar.gz to pool/main/libc/libcatalyst-modules-perl/libcatalyst-modules-perl_0.04.tar.gz libcatalyst-modules-perl_0.04_all.deb to pool/main/libc/libcatalyst-modules-perl/libcatalyst-modules-perl_0.04_all.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted linux-kernel-di-i386-2.6 1.14 (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Thu, 17 Nov 2005 15:52:37 -0500 Source: linux-kernel-di-i386-2.6 Binary: xfs-modules-2.6.14-2-386-di irda-modules-2.6.14-2-386-di ide-core-modules-2.6.14-2-386-di scsi-core-modules-2.6.14-2-386-di socket-modules-2.6.14-2-386-di reiserfs-modules-2.6.14-2-386-di input-modules-2.6.14-2-386-di serial-modules-2.6.14-2-386-di jfs-modules-2.6.14-2-386-di cdrom-core-modules-2.6.14-2-386-di fat-modules-2.6.14-2-386-di ext3-modules-2.6.14-2-386-di loop-modules-2.6.14-2-386-di cdrom-modules-2.6.14-2-386-di sata-modules-2.6.14-2-386-di fb-modules-2.6.14-2-386-di plip-modules-2.6.14-2-386-di nic-extra-modules-2.6.14-2-386-di ufs-modules-2.6.14-2-386-di mouse-modules-2.6.14-2-386-di ide-modules-2.6.14-2-386-di usb-modules-2.6.14-2-386-di pcmcia-modules-2.6.14-2-386-di md-modules-2.6.14-2-386-di scsi-common-modules-2.6.14-2-386-di usb-storage-modules-2.6.14-2-386-di ppp-modules-2.6.14-2-386-di floppy-modules-2.6.14-2-386-di acpi-modules-2.6.14-2-386-di nic-usb-modules-2.6.14-2-386-di kernel-image-2.6.14-2-386-di parport-modules-2.6.14-2-386-di pcmcia-storage-modules-2.6.14-2-386-di crc-modules-2.6.14-2-386-di ipv6-modules-2.6.14-2-386-di qnx4-modules-2.6.14-2-386-di firmware-modules-2.6.14-2-386-di nic-pcmcia-modules-2.6.14-2-386-di scsi-extra-modules-2.6.14-2-386-di scsi-modules-2.6.14-2-386-di nic-modules-2.6.14-2-386-di nic-shared-modules-2.6.14-2-386-di firewire-core-modules-2.6.14-2-386-di ntfs-modules-2.6.14-2-386-di Architecture: source i386 Version: 1.14 Distribution: unstable Urgency: low Maintainer: Debian Install System Team debian-boot@lists.debian.org Changed-By: Joey Hess [EMAIL PROTECTED] Description: acpi-modules-2.6.14-2-386-di - ACPI support modules (udeb) cdrom-core-modules-2.6.14-2-386-di - CDROM support (udeb) cdrom-modules-2.6.14-2-386-di - Esoteric CDROM drivers (udeb) crc-modules-2.6.14-2-386-di - CRC modules (udeb) ext3-modules-2.6.14-2-386-di - EXT3 filesystem support (udeb) fat-modules-2.6.14-2-386-di - FAT filesystem support (udeb) fb-modules-2.6.14-2-386-di - Frame buffer support (udeb) firewire-core-modules-2.6.14-2-386-di - Core FireWire drivers (udeb) firmware-modules-2.6.14-2-386-di - Firmware request modules (udeb) floppy-modules-2.6.14-2-386-di - Floppy driver (udeb) ide-core-modules-2.6.14-2-386-di - IDE support (udeb) ide-modules-2.6.14-2-386-di - IDE drivers (udeb) input-modules-2.6.14-2-386-di - Input devices support (udeb) ipv6-modules-2.6.14-2-386-di - IPv6 driver (udeb) irda-modules-2.6.14-2-386-di - Infrared devices support (udeb) jfs-modules-2.6.14-2-386-di - JFS filesystem support (udeb) kernel-image-2.6.14-2-386-di - Linux kernel binary image for the Debian installer (udeb) loop-modules-2.6.14-2-386-di - Loopback filesystem support (udeb) md-modules-2.6.14-2-386-di - RAID and LVM support (udeb) mouse-modules-2.6.14-2-386-di - Mouse support (udeb) nic-extra-modules-2.6.14-2-386-di - Rare NIC drivers (udeb) nic-modules-2.6.14-2-386-di - Common NIC drivers (udeb) nic-pcmcia-modules-2.6.14-2-386-di - Common PCMCIA NIC drivers (udeb) nic-shared-modules-2.6.14-2-386-di - Shared NIC drivers (udeb) nic-usb-modules-2.6.14-2-386-di - USB NIC drivers (udeb) ntfs-modules-2.6.14-2-386-di - NTFS filesystem support (udeb) parport-modules-2.6.14-2-386-di - Parallel port support (udeb) pcmcia-modules-2.6.14-2-386-di - Common PCMCIA drivers (udeb) pcmcia-storage-modules-2.6.14-2-386-di - PCMCIA storage drivers (udeb) plip-modules-2.6.14-2-386-di - PLIP drivers (udeb) ppp-modules-2.6.14-2-386-di - PPP drivers (udeb) qnx4-modules-2.6.14-2-386-di - QNX4 filesystem support (udeb) reiserfs-modules-2.6.14-2-386-di - Reiser filesystem support (udeb) sata-modules-2.6.14-2-386-di - SATA drivers (udeb) scsi-common-modules-2.6.14-2-386-di - Very common SCSI drivers (udeb) scsi-core-modules-2.6.14-2-386-di - Core SCSI subsystem (udeb) scsi-extra-modules-2.6.14-2-386-di - Uncommon SCSI drivers (udeb) scsi-modules-2.6.14-2-386-di - SCSI drivers (udeb) serial-modules-2.6.14-2-386-di - Serial drivers (udeb) socket-modules-2.6.14-2-386-di - Socket drivers (udeb) ufs-modules-2.6.14-2-386-di - UFS filesystem support (udeb) usb-modules-2.6.14-2-386-di - USB support (udeb) usb-storage-modules-2.6.14-2-386-di - USB storage support (udeb) xfs-modules-2.6.14-2-386-di - XFS filesystem support (udeb) Changes: linux-kernel-di-i386-2.6 (1.14) unstable; urgency=low . * Rebuilt with 2.6.14-3 (soversion bumped to -2 in that release). * fbcon compiled in Files: 7cc574f86d2cb62785fe5d5d27369c14 2018 debian-installer optional linux-kernel-di-i386-2.6_1.14.dsc be4e782cc48c4612de7e4ad6d7803e04 6853 debian-installer optional linux-kernel-di-i386-2.6_1.14.tar.gz ef8bbf2343cac461fc7731faea4cdadc 1458782 debian-installer extra kernel-image-2.6.14-2-386-di_1.14_i386.udeb 1251d842c3d9b35125996f5b0cabdc44 163294 debian-installer standard nic-modules-2.6.14-2-386-di_1.14_i386.udeb
Accepted fakepop 8 (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Mon, 21 Nov 2005 13:35:51 -0200 Source: fakepop Binary: fakepop Architecture: source i386 Version: 8 Distribution: unstable Urgency: low Maintainer: Pedro Zorzenon Neto [EMAIL PROTECTED] Changed-By: Pedro Zorzenon Neto [EMAIL PROTECTED] Description: fakepop- fake pop3 daemon. delivers same messages to all users Closes: 340170 Changes: fakepop (8) unstable; urgency=low . * Bugfix: added \r\n to output of POP command LIST. Thanks to Robert L Mathews (closes: #340170) Files: 1b4cbd0608db6b1ee3acb2b2d2e9e2b5 512 mail extra fakepop_8.dsc 8b11a1e05712fb1f24bfdff1c95ee603 8391 mail extra fakepop_8.tar.gz c7541444006389c3ee6eb6e12f45e8d0 9814 mail extra fakepop_8_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFDgeqlOcl5Y3J0qgcRAuB7AJ4tSH21xTr+ppTWGQMkCR0AkIsPkQCglStA 6gOgkdrlFFnFRV3cWKgR5vc= =16OO -END PGP SIGNATURE- Accepted: fakepop_8.dsc to pool/main/f/fakepop/fakepop_8.dsc fakepop_8.tar.gz to pool/main/f/fakepop/fakepop_8.tar.gz fakepop_8_i386.deb to pool/main/f/fakepop/fakepop_8_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted devscripts 2.9.9 (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Mon, 21 Nov 2005 10:46:49 -0500 Source: devscripts Binary: devscripts Architecture: source i386 Version: 2.9.9 Distribution: unstable Urgency: low Maintainer: Julian Gilbey [EMAIL PROTECTED] Changed-By: Joey Hess [EMAIL PROTECTED] Description: devscripts - Scripts to make the life of a Debian Package maintainer easier Closes: 335181 336025 336632 337829 338171 Changes: devscripts (2.9.9) unstable; urgency=low . [ Filippo Giunchedi ] * uscan: add option to set LWP timeout, patch by Stephen Quinney (Closes: #335181) . [ Julian Gilbey ] * bts: fix handling of arguments to show command; translate tag:... into include=... when given as a second argument (Closes: #338171) * bts: don't treat something like bts close #123456 as a comment * debchange: reapply --edit patch from bug#234434 (Closes: #336632) * debcommit: fix version grepping in changelog parsing (Closes: #336025) * debdiff: add --quiet switch and set exit status according to diff status (Closes: #337829) * debuild: improve grammar of usage message . [ Joey Hess ] * bts: sleep a default of 5 seconds between bts cache downloads to avoid hammering the underprovisioned debian BTS/master archive server. * bts: add --cache-delay parameter to tune this Files: cd9e081cba659871614ff26a8712f7a0 683 devel optional devscripts_2.9.9.dsc 9f0ce6038c165e72817e833c2e04e12a 324729 devel optional devscripts_2.9.9.tar.gz 75fca7d6780a04eacf342f0694391ad4 290064 devel optional devscripts_2.9.9_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDgez62tp5zXiKP0wRAnh1AJ9JcsTUp7TA1aUHHGdASwj4VNOoSACdGqU6 vIoyZ5lP1XWtc1FiBnnzqfM= =SGyl -END PGP SIGNATURE- Accepted: devscripts_2.9.9.dsc to pool/main/d/devscripts/devscripts_2.9.9.dsc devscripts_2.9.9.tar.gz to pool/main/d/devscripts/devscripts_2.9.9.tar.gz devscripts_2.9.9_i386.deb to pool/main/d/devscripts/devscripts_2.9.9_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted fail2ban 0.6.0-1 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Sun, 20 Nov 2005 14:56:41 -0500 Source: fail2ban Binary: fail2ban Architecture: source all Version: 0.6.0-1 Distribution: unstable Urgency: low Maintainer: [EMAIL PROTECTED] Changed-By: Yaroslav Halchenko [EMAIL PROTECTED] Description: fail2ban - bans IPs that cause multiple authentication errors Changes: fail2ban (0.6.0-1) unstable; urgency=low . * Merged with the latest stable upstream release. That incure some changes for the Debian configuration of the package to be more upstream-like. Visible one is: subject in the sent email includes section outside of [Fail2Ban] * Updated README.Debian to answer possible question regarding effective bantime starting moment Files: b49a400f25675fb0692516ce92297f90 611 net optional fail2ban_0.6.0-1.dsc f1da61eeb28a7c835b97baa9e040218a 22299 net optional fail2ban_0.6.0.orig.tar.gz a4c8f91b85c347ed520ba9b9fdd228b2 12764 net optional fail2ban_0.6.0-1.diff.gz e78bfb4b673fa9045b12fe98901094f3 33532 net optional fail2ban_0.6.0-1_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFDgfkpLz4Gnv7CP7IRAqETAJ9m8HFEKvOCGsToeZ9swEoOzOYgRgCfW2Ox i+jzpyZsVlJ+v92BB4BjBCs= =zDhY -END PGP SIGNATURE- Accepted: fail2ban_0.6.0-1.diff.gz to pool/main/f/fail2ban/fail2ban_0.6.0-1.diff.gz fail2ban_0.6.0-1.dsc to pool/main/f/fail2ban/fail2ban_0.6.0-1.dsc fail2ban_0.6.0-1_all.deb to pool/main/f/fail2ban/fail2ban_0.6.0-1_all.deb fail2ban_0.6.0.orig.tar.gz to pool/main/f/fail2ban/fail2ban_0.6.0.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted alleyoop 0.9.0-4 (source i386)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Format: 1.7
Date: Mon, 21 Nov 2005 18:04:12 +0100
Source: alleyoop
Binary: alleyoop
Architecture: source i386
Version: 0.9.0-4
Distribution: unstable
Urgency: high
Maintainer: Carlos Perelló MarÃn [EMAIL PROTECTED]
Changed-By: Loic Minier [EMAIL PROTECTED]
Description:
alleyoop - Front-end to the Valgrind memory checker
Closes: 340173
Changes:
alleyoop (0.9.0-4) unstable; urgency=high
.
* Add ${misc:Depends} to Depends. (Closes: #340173)
[debian/control, debian/control.in]
Files:
bbbd5a99b06906ad09fff0dab5f073e6 1644 devel optional alleyoop_0.9.0-4.dsc
f09cc0248df47cb50cd44ea634c79bb5 6310 devel optional alleyoop_0.9.0-4.diff.gz
e6d50482e00ce6f89709538662ecb15a 406966 devel optional
alleyoop_0.9.0-4_i386.deb
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2 (GNU/Linux)
iD8DBQFDggNe4VUX8isJIMARAiI+AJ93yZR9S6n4WPmM3BkfZUMrl1w3/ACdGmOj
DJ9dQvslGwzWIM3zyq1x/y0=
=jRyK
-END PGP SIGNATURE-
Accepted:
alleyoop_0.9.0-4.diff.gz
to pool/main/a/alleyoop/alleyoop_0.9.0-4.diff.gz
alleyoop_0.9.0-4.dsc
to pool/main/a/alleyoop/alleyoop_0.9.0-4.dsc
alleyoop_0.9.0-4_i386.deb
to pool/main/a/alleyoop/alleyoop_0.9.0-4_i386.deb
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted mono 1.1.10-1 (source i386 all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Sat, 12 Nov 2005 21:54:15 +0200 Source: mono Binary: mono-classlib-1.0-dbg mono-classlib-2.0-dbg mono-jit mono-gac libmono0 mono libmono-dev mono-classlib-1.0 mono-common mono-assemblies-base mono-classlib-2.0 mono-mcs mono-gmcs mono-jay mono-utils mono-devel Architecture: source i386 all Version: 1.1.10-1 Distribution: unstable Urgency: low Maintainer: Debian Mono Group [EMAIL PROTECTED] Changed-By: Debian Mono Group [EMAIL PROTECTED] Description: libmono-dev - libraries for the Mono JIT - Development files libmono0 - libraries for the Mono JIT mono - Mono CLI (.NET) runtime mono-assemblies-base - Mono class library - transistion package mono-classlib-1.0 - Mono class library (1.0) mono-classlib-1.0-dbg - Mono class library (1.0) - debug symbols mono-classlib-2.0 - Mono class library (2.0) mono-classlib-2.0-dbg - Mono class library (2.0) - debug symbols mono-common - common files for Mono mono-devel - Mono CLI (.NET) runtime with development tools mono-gac - Mono GAC tool mono-gmcs - Mono C# 2.0 compiler mono-jay - LALR(1) parser generator oriented to Java/.NET mono-jit - fast CLI (.NET) JIT compiler for Mono mono-mcs - Mono C# compiler mono-utils - Mono utilities Closes: 333851 Changes: mono (1.1.10-1) unstable; urgency=low . * New upstream release * Mirco 'meebey' Bauer + debian/patches/00list: - Removed fix_xsp2_inherits, already applied upstream. - Removed datetime_doparse_fix, already applied upstream. - Removed s390_compile_fix, already applied upstream. - Removed 64bit_implicit_pointer_cast_fix, already applied upstream. + debian/mono-mcs.manpages: - Added mozroots.1 + debian/mono-classlib-1.0.install: - Added dotnet.pc + debian/control: - Added libgdiplus to Recommends of mono. (Closes: #333851) Files: ddc5e8b4a6a34e70e2c6b1d8a1167979 982 interpreters optional mono_1.1.10-1.dsc dd04088e82b7cf69a417fd06bddd9148 17083925 interpreters optional mono_1.1.10.orig.tar.gz d87515e471039098366b52a35f959b54 39129 interpreters optional mono_1.1.10-1.diff.gz ad5246c29448a14b133499f6a3d62346 38824 libs optional mono-assemblies-base_1.1.10-1_all.deb fc7c6779db4f35958f94c00fca57a8e4 4225208 libs optional mono-classlib-1.0_1.1.10-1_all.deb 69bb84bf479038517ea24b1359f7aeb2 3701442 libs extra mono-classlib-1.0-dbg_1.1.10-1_all.deb dcc2976cf9351b68597eb950259cf26e 4863402 libs optional mono-classlib-2.0_1.1.10-1_all.deb ddb96e2a2c957099596bd4620562a06e 4376544 libs extra mono-classlib-2.0-dbg_1.1.10-1_all.deb 322f0f18b5089deaced82cf4dc6e03d4 1406456 devel optional mono-mcs_1.1.10-1_all.deb 01fd23cf152a109426bb25ce228e299c 668932 devel optional mono-gmcs_1.1.10-1_all.deb e72ea712b9ef58009604a0366d51b50d 49792 devel optional mono-gac_1.1.10-1_all.deb b223393f6d70d00563cac7b0526c831d 112400 interpreters optional mono-common_1.1.10-1_i386.deb 457b8896f4232aa6baf7f45167e02c43 631194 interpreters optional mono-jit_1.1.10-1_i386.deb 7c825b4e4e3b64e41ff818c73913315d 1176 interpreters optional mono_1.1.10-1_i386.deb b1cfe5d6c5818da92caaa572379fb5b3 38860 devel optional mono-devel_1.1.10-1_i386.deb 35396c77850886e7b93d97f1163b3ee6 1016528 devel optional mono-utils_1.1.10-1_i386.deb 01b345fc46d1c4c1ab2116e047e8a888 768852 libs optional libmono0_1.1.10-1_i386.deb 358a8ed4bb53b56bc74f0deada5204bd 1004046 devel optional libmono-dev_1.1.10-1_i386.deb 332037a07e0cff547622c477c167f85b 49950 devel optional mono-jay_1.1.10-1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDggJE4XrXtQkN2NURAuJlAJ4scM7h78eoOS9rz3EErgLFVSzp5gCfXFph f0rXujgDwivbXxyJNbZVeVA= =336C -END PGP SIGNATURE- Accepted: libmono-dev_1.1.10-1_i386.deb to pool/main/m/mono/libmono-dev_1.1.10-1_i386.deb libmono0_1.1.10-1_i386.deb to pool/main/m/mono/libmono0_1.1.10-1_i386.deb mono-assemblies-base_1.1.10-1_all.deb to pool/main/m/mono/mono-assemblies-base_1.1.10-1_all.deb mono-classlib-1.0-dbg_1.1.10-1_all.deb to pool/main/m/mono/mono-classlib-1.0-dbg_1.1.10-1_all.deb mono-classlib-1.0_1.1.10-1_all.deb to pool/main/m/mono/mono-classlib-1.0_1.1.10-1_all.deb mono-classlib-2.0-dbg_1.1.10-1_all.deb to pool/main/m/mono/mono-classlib-2.0-dbg_1.1.10-1_all.deb mono-classlib-2.0_1.1.10-1_all.deb to pool/main/m/mono/mono-classlib-2.0_1.1.10-1_all.deb mono-common_1.1.10-1_i386.deb to pool/main/m/mono/mono-common_1.1.10-1_i386.deb mono-devel_1.1.10-1_i386.deb to pool/main/m/mono/mono-devel_1.1.10-1_i386.deb mono-gac_1.1.10-1_all.deb to pool/main/m/mono/mono-gac_1.1.10-1_all.deb mono-gmcs_1.1.10-1_all.deb to pool/main/m/mono/mono-gmcs_1.1.10-1_all.deb mono-jay_1.1.10-1_i386.deb to pool/main/m/mono/mono-jay_1.1.10-1_i386.deb mono-jit_1.1.10-1_i386.deb to pool/main/m/mono/mono-jit_1.1.10-1_i386.deb mono-mcs_1.1.10-1_all.deb to pool/main/m/mono/mono-mcs_1.1.10-1_all.deb mono-utils_1.1.10-1_i386.deb to
Accepted gtk-sharp2 2.4.0-1 (source i386 all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Sun, 13 Nov 2005 19:53:17 +0100 Source: gtk-sharp2 Binary: monodoc-gtk2.0-manual gtk-sharp2-examples gtk-sharp2-gapi libgnome2.0-cil libgtk2.0-cil libvte2.0-cil libgconf2.0-cil gtk-sharp2 libglib2.0-cil libglade2.0-cil Architecture: source i386 all Version: 2.4.0-1 Distribution: unstable Urgency: low Maintainer: Debian Mono Group [EMAIL PROTECTED] Changed-By: Debian Mono Group [EMAIL PROTECTED] Description: gtk-sharp2 - Gtk# 2.4 suite, CLI bindings for GTK+ and GNOME gtk-sharp2-examples - sample applications for the Gtk# 2.4 toolkit gtk-sharp2-gapi - C source parser and C# code generator for GObject based APIs libgconf2.0-cil - CLI binding for GConf 2.6 libglade2.0-cil - CLI binding for the Glade libraries 2.4 libglib2.0-cil - CLI binding for the GLib utility library 2.4 libgnome2.0-cil - CLI binding for GNOME 2.6 libgtk2.0-cil - CLI binding for the GTK+ toolkit 2.4 libvte2.0-cil - CLI binding for VTE 0.11 monodoc-gtk2.0-manual - compiled XML documentation for Gtk# 2.4 Changes: gtk-sharp2 (2.4.0-1) unstable; urgency=low . * New upstream release + This is the final stable release, thus dropping all unstable version marks in the package descriptions. * Mirco 'meebey' Bauer + Added missing gtk-dotnet-2.0.pc to libgtk2.0-cil package. + Updated all packages descriptions to match what the library binds. + Patch by Sebastian 'slomo' Dröge [EMAIL PROTECTED]: - Renamed source package to gtk-sharp2 as it's stable now - Moved glue libs from /usr/lib into /usr/lib/mono/gtk-sharp-2.0 - Less stricter clilibs. Upstream guarantees ABI compatibility from now on. Files: 9b22865e3451070afef7e6c96145da35 1434 libs optional gtk-sharp2_2.4.0-1.dsc 9c2e4283a104479d4c7f404142042f3a 2127668 libs optional gtk-sharp2_2.4.0.orig.tar.gz 4adde38ef15f5fcb4937b092378b35b4 8595 libs optional gtk-sharp2_2.4.0-1.diff.gz 265ec07c00f7d9da002ddb239a278eab 112272 libs optional gtk-sharp2_2.4.0-1_all.deb 9319e139dae269431b9936e84f678126 216252 libs optional gtk-sharp2-examples_2.4.0-1_all.deb bd6b291893558b1fbedf31ce09bf8693 122688 libs optional libgconf2.0-cil_2.4.0-1_all.deb 892e6e9c470264a7f05f22fce93f125e 2092084 doc extra monodoc-gtk2.0-manual_2.4.0-1_all.deb 0444a00823465a330a06687903f4ac0b 351418 libs optional gtk-sharp2-gapi_2.4.0-1_i386.deb af51fa6cf04ec23db57a44e2ed83d14a 139570 libs optional libglib2.0-cil_2.4.0-1_i386.deb f80e9b66917f85cc8413e48e55a079c4 545990 libs optional libgtk2.0-cil_2.4.0-1_i386.deb 521b988c3bc8455da88b9dd6b2adaf37 125578 libs optional libglade2.0-cil_2.4.0-1_i386.deb 4d00cda7f8a0c4875913021c8eca24c0 300092 libs optional libgnome2.0-cil_2.4.0-1_i386.deb 863ecce5433f66b0d0a03897e9075786 134734 libs optional libvte2.0-cil_2.4.0-1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDggI34XrXtQkN2NURAjPIAJ9v6MK1kU9DinXExi2Mq8v0VKvMvQCfXoTa x9x26qvCk/2UHxHmnp0wgzM= =zEqO -END PGP SIGNATURE- Accepted: gtk-sharp2-examples_2.4.0-1_all.deb to pool/main/g/gtk-sharp2/gtk-sharp2-examples_2.4.0-1_all.deb gtk-sharp2-gapi_2.4.0-1_i386.deb to pool/main/g/gtk-sharp2/gtk-sharp2-gapi_2.4.0-1_i386.deb gtk-sharp2_2.4.0-1.diff.gz to pool/main/g/gtk-sharp2/gtk-sharp2_2.4.0-1.diff.gz gtk-sharp2_2.4.0-1.dsc to pool/main/g/gtk-sharp2/gtk-sharp2_2.4.0-1.dsc gtk-sharp2_2.4.0-1_all.deb to pool/main/g/gtk-sharp2/gtk-sharp2_2.4.0-1_all.deb gtk-sharp2_2.4.0.orig.tar.gz to pool/main/g/gtk-sharp2/gtk-sharp2_2.4.0.orig.tar.gz libgconf2.0-cil_2.4.0-1_all.deb to pool/main/g/gtk-sharp2/libgconf2.0-cil_2.4.0-1_all.deb libglade2.0-cil_2.4.0-1_i386.deb to pool/main/g/gtk-sharp2/libglade2.0-cil_2.4.0-1_i386.deb libglib2.0-cil_2.4.0-1_i386.deb to pool/main/g/gtk-sharp2/libglib2.0-cil_2.4.0-1_i386.deb libgnome2.0-cil_2.4.0-1_i386.deb to pool/main/g/gtk-sharp2/libgnome2.0-cil_2.4.0-1_i386.deb libgtk2.0-cil_2.4.0-1_i386.deb to pool/main/g/gtk-sharp2/libgtk2.0-cil_2.4.0-1_i386.deb libvte2.0-cil_2.4.0-1_i386.deb to pool/main/g/gtk-sharp2/libvte2.0-cil_2.4.0-1_i386.deb monodoc-gtk2.0-manual_2.4.0-1_all.deb to pool/main/g/gtk-sharp2/monodoc-gtk2.0-manual_2.4.0-1_all.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted mono-tools 1.1.10-1 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Tue, 15 Nov 2005 15:54:49 +0200 Source: mono-tools Binary: gnunit monodoc-browser Architecture: source all Version: 1.1.10-1 Distribution: unstable Urgency: low Maintainer: Debian Mono Group [EMAIL PROTECTED] Changed-By: Debian Mono Group [EMAIL PROTECTED] Description: gnunit - frontend for running NUnit 2 test suites monodoc-browser - MonoDoc GTK+ based viewer Changes: mono-tools (1.1.10-1) unstable; urgency=low . * New upstream release * Mirco 'meebey' Bauer + debian/control: - Added Replaces: monodoc-base ( 1.1.9) to monodoc-browser for smooth upgrades from 1.0.x versions. + debian/monodoc-browser.install: - Added GtkHtmlHtmlRender.dll, new renderer for MonoDoc Browser. - Removed GeckoHtmlRender.dll, it's less stable than GtkHTML. + Removed 02_fix_buildsystem.dpatch, already applied upstream. Files: 1ee8a730f622fcb6d6010ae5fda618c5 945 devel optional mono-tools_1.1.10-1.dsc 1d0cce057b2c425ff5fb4ffc2f68d5f4 253798 devel optional mono-tools_1.1.10.orig.tar.gz e416ab925f87aed92c19d4aa6616039d 4286 devel optional mono-tools_1.1.10-1.diff.gz 12abb3d7d535aa5f8ce9ccfa93c5bc2f 66102 devel optional monodoc-browser_1.1.10-1_all.deb 28546dea19000290f102b8f9742f01f6 87834 devel optional gnunit_1.1.10-1_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDggJS4XrXtQkN2NURAu+KAJ9h7Lz/vnQBEDvuZ55SEIEvNFWBrACgr+sy Adk0c2ybCAB3dvsve9t7Kpo= =29Y+ -END PGP SIGNATURE- Accepted: gnunit_1.1.10-1_all.deb to pool/main/m/mono-tools/gnunit_1.1.10-1_all.deb mono-tools_1.1.10-1.diff.gz to pool/main/m/mono-tools/mono-tools_1.1.10-1.diff.gz mono-tools_1.1.10-1.dsc to pool/main/m/mono-tools/mono-tools_1.1.10-1.dsc mono-tools_1.1.10.orig.tar.gz to pool/main/m/mono-tools/mono-tools_1.1.10.orig.tar.gz monodoc-browser_1.1.10-1_all.deb to pool/main/m/mono-tools/monodoc-browser_1.1.10-1_all.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted gnue-appserver 0.4.3-1 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Sat, 22 Oct 2005 23:15:27 +1300 Source: gnue-appserver Binary: gnue-appserver Architecture: source all Version: 0.4.3-1 Distribution: unstable Urgency: low Maintainer: Andrew Mitchell [EMAIL PROTECTED] Changed-By: Andrew Mitchell [EMAIL PROTECTED] Description: gnue-appserver - GNU Enterprise Application Server Changes: gnue-appserver (0.4.3-1) unstable; urgency=low . * New upstream release Files: c289589f806071bc768aa195afd9bcc8 680 interpreters optional gnue-appserver_0.4.3-1.dsc 89c0bad2a43d435b6c2a518c4f9bed18 436490 interpreters optional gnue-appserver_0.4.3.orig.tar.gz e067478cb7b6eb4008032d2fea1a2e65 3305 interpreters optional gnue-appserver_0.4.3-1.diff.gz 6b4592e34135fa50eb8c231ed53f9148 249138 interpreters optional gnue-appserver_0.4.3-1_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDgg8PggkdmlkhtdgRAv2RAJ4y7qTOWfe31mGeONo82vqm9etwXACfdq7M sPl/11pJD0acFr8b/84vNM4= =ltZG -END PGP SIGNATURE- Accepted: gnue-appserver_0.4.3-1.diff.gz to pool/main/g/gnue-appserver/gnue-appserver_0.4.3-1.diff.gz gnue-appserver_0.4.3-1.dsc to pool/main/g/gnue-appserver/gnue-appserver_0.4.3-1.dsc gnue-appserver_0.4.3-1_all.deb to pool/main/g/gnue-appserver/gnue-appserver_0.4.3-1_all.deb gnue-appserver_0.4.3.orig.tar.gz to pool/main/g/gnue-appserver/gnue-appserver_0.4.3.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted gnue-common 0.6.1-1 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Sat, 22 Oct 2005 22:38:09 +1300 Source: gnue-common Binary: gnue-common Architecture: source all Version: 0.6.1-1 Distribution: unstable Urgency: low Maintainer: Andrew Mitchell [EMAIL PROTECTED] Changed-By: Andrew Mitchell [EMAIL PROTECTED] Description: gnue-common - GNU Enterprise Common Library for use with the GNUe tools Changes: gnue-common (0.6.1-1) unstable; urgency=low . * New upstream release * Changed Maintainer email address Files: c449c316340cdb16da4b37a263915c7b 625 interpreters optional gnue-common_0.6.1-1.dsc ded65aceb4b610a17fc87ecc266ae912 1703458 interpreters optional gnue-common_0.6.1.orig.tar.gz be157a85b7c4b1591286a2b85e0b8042 3657 interpreters optional gnue-common_0.6.1-1.diff.gz d6de2e7047f3920efe5f1beae66e9c3a 1218852 interpreters optional gnue-common_0.6.1-1_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDgg7rggkdmlkhtdgRAtMzAJ44bV6Rhy3ASBQ4CGVDqmSkstjt0ACfbbHd 2U7/c+Qky9NjkRnUzwUjP8w= =esVZ -END PGP SIGNATURE- Accepted: gnue-common_0.6.1-1.diff.gz to pool/main/g/gnue-common/gnue-common_0.6.1-1.diff.gz gnue-common_0.6.1-1.dsc to pool/main/g/gnue-common/gnue-common_0.6.1-1.dsc gnue-common_0.6.1-1_all.deb to pool/main/g/gnue-common/gnue-common_0.6.1-1_all.deb gnue-common_0.6.1.orig.tar.gz to pool/main/g/gnue-common/gnue-common_0.6.1.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted gnue-forms 0.5.13-1 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Sat, 22 Oct 2005 22:56:09 +1300 Source: gnue-forms Binary: gnue-forms Architecture: source all Version: 0.5.13-1 Distribution: unstable Urgency: low Maintainer: Andrew Mitchell [EMAIL PROTECTED] Changed-By: Andrew Mitchell [EMAIL PROTECTED] Description: gnue-forms - An XML-based forms painter Changes: gnue-forms (0.5.13-1) unstable; urgency=low . * New upstream release * Update Depends for gnue-common 0.6.1 * Changed Maintainer email address Files: 6982f5e87a6ff11bca4b71f39e62167c 682 interpreters optional gnue-forms_0.5.13-1.dsc f684442dc0f25737ead22dff01c30a70 689013 interpreters optional gnue-forms_0.5.13.orig.tar.gz cb742ac39c7f1b834057259344d2b899 3940 interpreters optional gnue-forms_0.5.13-1.diff.gz 9476b53d6cdb4b4176f3bbf6fac3a168 616008 interpreters optional gnue-forms_0.5.13-1_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDgg89ggkdmlkhtdgRAnkDAJ98bDDqlQ91jVODkQs5kjPUZkSWnwCfWAgw 0cH/DZDCg3BzX5BVRcdRqEY= =bPK6 -END PGP SIGNATURE- Accepted: gnue-forms_0.5.13-1.diff.gz to pool/main/g/gnue-forms/gnue-forms_0.5.13-1.diff.gz gnue-forms_0.5.13-1.dsc to pool/main/g/gnue-forms/gnue-forms_0.5.13-1.dsc gnue-forms_0.5.13-1_all.deb to pool/main/g/gnue-forms/gnue-forms_0.5.13-1_all.deb gnue-forms_0.5.13.orig.tar.gz to pool/main/g/gnue-forms/gnue-forms_0.5.13.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted horde2 2.2.9-1 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Mon, 21 Nov 2005 20:03:22 +0100 Source: horde2 Binary: horde2 Architecture: source all Version: 2.2.9-1 Distribution: unstable Urgency: high Maintainer: Ola Lundqvist [EMAIL PROTECTED] Changed-By: Ola Lundqvist [EMAIL PROTECTED] Description: horde2 - horde web application suite Closes: 338983 Changes: horde2 (2.2.9-1) unstable; urgency=high . * New upstream release. This release fix a cross site scripting vulnerability (CVE-2005-3570), closes: #338983. Files: 3ef2d764423af157b6ccd03271ec287b 563 web optional horde2_2.2.9-1.dsc 0d1a8a52ee69307fe2d687edd0b1c3c8 683026 web optional horde2_2.2.9.orig.tar.gz 3d18604e6014112ae9f9a1dc8172dbc9 59567 web optional horde2_2.2.9-1.diff.gz d74d1ea1853a3213335f36719ce1958f 528996 web optional horde2_2.2.9-1_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDghp3GKGxzw/lPdkRAhQgAJ9jxpJmbdEamOhJPyj8F+XbjzLhJgCfTMRr b9TECUZxUOozfWq1HUu99Xo= =tHXE -END PGP SIGNATURE- Accepted: horde2_2.2.9-1.diff.gz to pool/main/h/horde2/horde2_2.2.9-1.diff.gz horde2_2.2.9-1.dsc to pool/main/h/horde2/horde2_2.2.9-1.dsc horde2_2.2.9-1_all.deb to pool/main/h/horde2/horde2_2.2.9-1_all.deb horde2_2.2.9.orig.tar.gz to pool/main/h/horde2/horde2_2.2.9.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
