Running x86-64 debian inside i386 pbuilder on AMD64
Hello, I am looking to create .deb's for x86-64. I have an AMD64 but run an i386 OS due to the lack of some 64-bit packages (like flash and what-not). I have pbuilder all set up to build packages for i386, but I wonder if it's possible to use it to create x86-64 packages as well. After all, I do have an AMD64 so I can run x86-64 packages. So, is it possible to bootstrap an x86-64 OS with pbuilder on an i386 system running on an AMD64? Thanks in advance, -- Sander Marechal http://www.gnome-hearts.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Time to rethink ifupdown
Hello, On Wed, Aug 23, 2006 at 04:45:52PM +0100, martin f krafft wrote: also sprach Alexey Feldgendler [EMAIL PROTECTED] [2006.08.23.1634 +0100]: It's an idea with the final goal to provide most of what ifupdown+guessnet+resolvconf do now, I would personally add ifrename to this list. I would suggest udev instead. with better integration with wireless-tools/wpasupplicant and ifplugd, ...but, actually, I think that everything should be integrated by adding files to .d-style directories like resolvconf is integrated into ifupdown, rather than built in like basic configuration of IPv4 interfaces is built into ifupdown. yes, and as it is, I consider it pretty hacky. Don't worry, I am a fan of componentised architectures and plugins. :) and a proper interface for user interfaces. What do you mean under this? Like a HAL interface, or a socket, so we can have GNOME/KDE applications easily configure networks on laptops. What about creating a DBUS interface - it can be integrated in any language that support it, and can be integrated in a GUI application. Kind regard Sylvain Le Gall -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Time to rethink ifupdown
On Thu, 24 Aug 2006 13:27:26 +0700, Sylvain Le Gall [EMAIL PROTECTED] wrote: What about creating a DBUS interface - it can be integrated in any language that support it, and can be integrated in a GUI application. Introducing dependencies on DBUS into a package essential to system operation doesn't sound like a very good idea to me. -- Alexey Feldgendler [EMAIL PROTECTED] [ICQ: 115226275] http://feldgendler.livejournal.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Running x86-64 debian inside i386 pbuilder on AMD64
* Sander Marechal [EMAIL PROTECTED] [2006-08-24 08:05]: I am looking to create .deb's for x86-64. I have an AMD64 but run an i386 OS due to the lack of some 64-bit packages (like flash and what-not). I have pbuilder all set up to build packages for i386, but I wonder if it's possible to use it to create x86-64 packages as well. After all, I do have an AMD64 so I can run x86-64 packages. So, is it possible to bootstrap an x86-64 OS with pbuilder on an i386 system running on an AMD64? If you are running a 64bit Kernel this should be possible. I run amd64 with linux32 installed and a 32bit dchroot for stuff like flash and co. yours Martin -- [EMAIL PROTECTED] Debian GNU/Linux - The Universal Operating System NForcer Nene, sie mag keine Horrofilme.. Schnulzen fallen da mit drunter :)) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Time to rethink ifupdown
also sprach Miles Bader [EMAIL PROTECTED] [2006.08.24.0334 +0100]: Python (and any language that depends on vast amounts of installed infrastructure) seems a bit dodgy for a core low-level facility. It's a great language to develop stuff at a moderate speed. Also note that much of Debian started out as Perl. I won't compare the two, but it's basically the same. And there is python-minimal and I have heard rumours that it will be in base soon. -- Please do not send copies of list mail to me; I read the list! .''`. martin f. krafft [EMAIL PROTECTED] : :' :proud Debian developer, author, administrator, and user `. `'` http://people.debian.org/~madduck http://debiansystem.info `- Debian - when you have better things to do than fixing systems never trust an operating system for which you do not have the source. -- source unknown signature.asc Description: Digital signature (GPG/PGP)
Re: Time to rethink ifupdown
also sprach Sylvain Le Gall [EMAIL PROTECTED] [2006.08.24.0727 +0100]: What about creating a DBUS interface - it can be integrated in any language that support it, and can be integrated in a GUI application. HAL, DBUS, whatever. I don't pretend to know anything about this magic stuff, but yeah.. -- Please do not send copies of list mail to me; I read the list! .''`. martin f. krafft [EMAIL PROTECTED] : :' :proud Debian developer, author, administrator, and user `. `'` http://people.debian.org/~madduck http://debiansystem.info `- Debian - when you have better things to do than fixing systems this message represents the official view of the voices in my head. signature.asc Description: Digital signature (GPG/PGP)
Re: Time to rethink ifupdown
also sprach Alexey Feldgendler [EMAIL PROTECTED] [2006.08.24.0811 +0100]: Introducing dependencies on DBUS into a package essential to system operation doesn't sound like a very good idea to me. Take a p Take a l Take a u Take a g Take a i Take a n and mix and stir with Suggests -- Please do not send copies of list mail to me; I read the list! .''`. martin f. krafft [EMAIL PROTECTED] : :' :proud Debian developer, author, administrator, and user `. `'` http://people.debian.org/~madduck http://debiansystem.info `- Debian - when you have better things to do than fixing systems quidquid latine dictum sit, altum viditur. signature.asc Description: Digital signature (GPG/PGP)
debconf and substitution of non-translated text
hey d-d, on the heels (or perhaps in the recent footsteps) of the discussion regarding update-manager and the faults of arbitrarily substituting strings in pre-translated text... i have a package (dbconfig-common), which via debconf's register system shares a set of pre-defined templates between any number of packages that use it. to customize these questions and make them as generic as possible for translators, i make fairly widespread use of db_subst. for example, you might have: Template: dbconfig-common/dbconfig-install ... _Description: Configure database for ${pkg} with dbconfig-common? ... now the question i have, being one whose charset-fu is not all it ought to be: what happens when i use db_subst with arbitrary text defined outside of a template? for example, ${pkg} is the package name, which is passed as an argument by the packager to the hook function in the maintainer scripts. my fear is that this will break things for users of non-western locales, am i correct? if i'm not correct and this isn't a problem, then please disregard the rest of this email :) from what i can tell, the way d-i works around this kind of problem is that it defines the substituting text as translatable descriptions of titles in debconf, and it uses db_metaget to fetch the values. this will work for some of the text in my case, where the strings can be predefined (like names of supported database types, etc). however, there are some strings that will be variable based on the package in question. for example, ${pkg}. if this is indeed a problem, it would be ideal to have a way to work around it without requiring more work from packagers. given that these extra strings are just package names and file names (thus they don't need to be translated per se) would doing some kind of locale check + iconv be an acceptable way around the problem? for example: to_lang=`locale | grep LANG` translated_string=`echo string_to_translate | iconv -f C -t $to_lang` thanks, sean -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
python-minimal in base?
On Thu, Aug 24, 2006 at 08:43:22AM +0100, martin f krafft wrote: Also note that much of Debian started out as Perl. I won't compare the two, but it's basically the same. And there is python-minimal and I have heard rumours that it will be in base soon. What? What? What? Can you expand on this rumor (you or someone else)? I was postponing a post on debian-devel asking about having some sort of python in base since I developed a tool for managing vim add-ons in python, but I'm scared about uploading it with a dependency on python (since it should be shipped with vim itself). More generally we have core tools developed in python (e.g. reportbug), and it's a pity not having the minimal needed python support for them in base. I'm thus totally interested in such a rumor :-) -- 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: python-minimal in base?
also sprach Stefano Zacchiroli [EMAIL PROTECTED] [2006.08.24.0923 +0100]: On Thu, Aug 24, 2006 at 08:43:22AM +0100, martin f krafft wrote: Also note that much of Debian started out as Perl. I won't compare the two, but it's basically the same. And there is python-minimal and I have heard rumours that it will be in base soon. What? What? What? Ah, rumours. So I have to rephrase what I wrote. I've heard talk about python in base, but not that it's been decided. This was around the Python BoF in Mexico. The discussion was postponed post-etch though. Sorry for bringing it up. Can we please postpone it again? -- Please do not send copies of list mail to me; I read the list! .''`. martin f. krafft [EMAIL PROTECTED] : :' :proud Debian developer, author, administrator, and user `. `'` http://people.debian.org/~madduck http://debiansystem.info `- Debian - when you have better things to do than fixing systems no, 'eureka' is greek for 'this bath is too hot.' -- dr. who signature.asc Description: Digital signature (GPG/PGP)
Re: These new diffs are great, but...
* Goswin von Brederlow: However, patching rred to apply patches in a single run would be a good start because all further optimizations will need it. Why should the number of chunks matter? If you use the naïve algorithm, it does. But rred implements something more involved, leading to a O(patch-files * lines + changes) complexity (or something very similar). What matters is reading, parsing and writing the file O(lines) and then the number of changes (lines of changes) O(changes). Combined this gives O(lines + changes) if the file is read once at the start and then all patches are applied. I guess you'll find it very hard to get down to O(lines + changes). 8-) Either you need to make multiple passes over the original file (like the current code does), or you need to combine patch files before applying them. The latter involves some kind of sorting, and unless you postulate an upper bound on the number of lines in a file, you'll end up with super-linear complexity. You can do that by combining the individual patch files or by teaching rred to do a single run with multiple patch files. Same result. Both solve the problem of O(lines * chunks + changes) complexity. The real problem is that APT's architecture doesn't allow rred to look at all patches at once. At least that's what I've been told. As for using pointers to lines and shuffeling them that seems to be the only sane thing to do. All patch operations are line based so it is essential that a line can be found and replaced in O(1). A simple array of pointers to lines solves that. Inserting in the middle of an array is not a constant-time operation. That's why the naïve algorithm is slow.
Re: python-minimal in base?
On Thu, Aug 24, 2006 at 10:23:46AM +0200, Stefano Zacchiroli wrote: On Thu, Aug 24, 2006 at 08:43:22AM +0100, martin f krafft wrote: Also note that much of Debian started out as Perl. I won't compare the two, but it's basically the same. And there is python-minimal and I have heard rumours that it will be in base soon. What? What? What? Can you expand on this rumor (you or someone else)? I was postponing a post on debian-devel asking about having some sort of python in base since I developed a tool for managing vim add-ons in python, but I'm scared about uploading it with a dependency on python (since it should be shipped with vim itself). More generally we have core tools developed in python (e.g. reportbug), and it's a pity not having the minimal needed python support for them in base. Frankly, I think the fact that Debian has a python-minimal package at *all* is deplorable. When this package first snuck into Debian from Ubuntu, it was stated quite clearly in the following discussion that upstream considered it completely unacceptable for anyone to ship python in such a state that users would end up with less than the full python suite installed on their system. The *only* reason for the split between python and python-minimal in Ubuntu is because python-minimal is Essential: yes, and the only reason this split is *acceptable* to upstream is that python itself is also part of the base system (Priority: important). Given that there has been no decision to include python-minimal in the set of essential packages for Debian, and python hasn't been promoted to the base system for Debian, it's totally premature for this package to even exist in Debian. The only goal this package serves is to make it convenient for the maintainer to maintain the package for both Debian and Ubuntu from a single source; in all other respects, it's bad for Debian. And the python2.4-minimal package even has reverse-dependencies in unstable now. sigh -- 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: debconf and substitution of non-translated text
On Thu, Aug 24, 2006 at 09:05:38AM +0200, sean finney wrote: i have a package (dbconfig-common), which via debconf's register system shares a set of pre-defined templates between any number of packages that use it. to customize these questions and make them as generic as possible for translators, i make fairly widespread use of db_subst. for example, you might have: Template: dbconfig-common/dbconfig-install ... _Description: Configure database for ${pkg} with dbconfig-common? ... now the question i have, being one whose charset-fu is not all it ought to be: what happens when i use db_subst with arbitrary text defined outside of a template? for example, ${pkg} is the package name, which is passed as an argument by the packager to the hook function in the maintainer scripts. A package name should be treated as a literal, of course, regardless of language. While in some languages the particulars of a package name may trigger inflection of surrounding words, we've been using this form for PHP debconf templates for years now and I haven't had any complaints from translators (or users) so far. Substitutions other than package names and filenames are probably a bad idea though. Cheers, -- 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: Time to rethink ifupdown
martin f krafft [EMAIL PROTECTED] writes: Python (and any language that depends on vast amounts of installed infrastructure) seems a bit dodgy for a core low-level facility. It's a great language to develop stuff at a moderate speed. It may well be (kinda ugly though) -- but that doesn't mean it's appropriate for a core system facility, which often needs to work even when the system is in a degraded state. -Miles -- `...the Soviet Union was sliding in to an economic collapse so comprehensive that in the end its factories produced not goods but bads: finished products less valuable than the raw materials they were made from.' [The Economist] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: debconf and substitution of non-translated text
A package name should be treated as a literal, of course, regardless of language. While in some languages the particulars of a package name may trigger inflection of surrounding words, we've been using this form for PHP debconf templates for years now and I haven't had any complaints from translators (or users) so far. Yeah, I see sean's actions in dbconfig-common mostly correct. Otherwise, I would have warned him already (I helped rewording the debconf templates to fit my personal fascist way of wording debconf templates). Theoretically, even there we could have problems. But minor, indeed. For instance, in French, translating this: The configuration of ${pkg} will be changed Becomes: La configuration de ${pkg} sera modifiée. If pkg=mysql, this becomes: La configuration de mysql sera modifiée. But, if pkg=apache, this becomes: La configuration de apache sera modifiée. While it should be: La configuration d'apache sera modifiée. So, indeed, there may be situations where substituting package names can lead to slightly incorrect translations. However, I think that we can live with it when we consider the benefits of DB_SUBST. signature.asc Description: Digital signature
Re: Time to rethink ifupdown
On 8/24/06, Miles Bader [EMAIL PROTECTED] wrote: martin f krafft [EMAIL PROTECTED] writes: Python (and any language that depends on vast amounts of installed infrastructure) seems a bit dodgy for a core low-level facility. It's a great language to develop stuff at a moderate speed. It may well be (kinda ugly though) -- but that doesn't mean it's appropriate for a core system facility, which often needs to work even when the system is in a degraded state. If such a facility was written in Python, it couldn't run with /usr unreadable. That could cause problems on a corrupted disk. (That's not to say I don't support writing it in Python, I love Python!) IANADD, andrew -Miles -- `...the Soviet Union was sliding in to an economic collapse so comprehensive that in the end its factories produced not goods but bads: finished products less valuable than the raw materials they were made from.' [The Economist] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- Andrew Donnellan http://andrewdonnellan.com http://ajdlinux.blogspot.com Jabber - [EMAIL PROTECTED] GPG - hkp://subkeys.pgp.net 0x5D4C0C58 --- Member of Linux Australia - http://linux.org.au Debian user - http://debian.org Get free rewards - http://ezyrewards.com/?id=23484 OpenNIC user - http://www.opennic.unrated.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: debconf and substitution of non-translated text
On Thu, Aug 24, 2006 at 11:41:11AM +0200, Christian Perrier wrote: For instance, in French, translating this: The configuration of ${pkg} will be changed Becomes: La configuration de ${pkg} sera modifiée. If pkg=mysql, this becomes: La configuration de mysql sera modifiée. But, if pkg=apache, this becomes: La configuration de apache sera modifiée. While it should be: La configuration d'apache sera modifiée. Which can probably be worked around as La configuration du paquet «${pkg}» sera modifiée. or a similar construction, no? -- 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/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Time to rethink ifupdown
also sprach Miles Bader [EMAIL PROTECTED] [2006.08.24.0958 +0100]: It may well be (kinda ugly though) -- but that doesn't mean it's appropriate for a core system facility, which often needs to work even when the system is in a degraded state. Let me set this straight: I have no intention to develop netconf and declare it default. I also see no reason to run netconf on servers at first. I want to develop netconf primarily for client machines, but keep flexibility in mind. If it proves to be useful and if people start adopting it, maybe it'll eventually replace ifupdown. This is not for me to decide. Yet it should be my goal to get people to *want* it to become the ifupdown replacement, because that'll mean I did it right. And to be honest: I am thinking Python because I finally would like to start working on a Python project from scratch. So far, I've worked a lot with Python, but mostly on other people's code, and I have not really had a lot of opportunity to develop applications lately. From all I can see, however, POSIX shell might be just as applicable, actually. After all, you can do quite a lot with it, you can optimise it for speed, it's easy to draft and maintain, it's in base already, and netconf is really only an integration framework for other tools. Take iproute+iwconfig+wpasupplicant+run-parts and consider guessnet+resolvconf, or consider reimplementing those, and you pretty much have everything you need. If DBUS/HAL interface, or socket interface is needed, well, one could always conceive a daemon that then fires off the appropriate netconf commands. While I'm at it, here's my plan: I won't have time to work on netconf for a long while. In fact, I have declared it to be my project for Debcamp in Edinburgh, so that's 9-11 months from now. During that time, I would like to keep collecting ideas on the wiki, so that I can spend a full week implementing the basics. Extreme programming is for wussies anyway. :) If, however, in the mean time, someone wants to step up and actually work on this, I'd be happy to cooperate, though without contributing code, so more as a back-patter/mentor/shoulder-to-cry-on/advisor/resource. All I ask is to be kept in the loop. -- Please do not send copies of list mail to me; I read the list! .''`. martin f. krafft [EMAIL PROTECTED] : :' :proud Debian developer, author, administrator, and user `. `'` http://people.debian.org/~madduck http://debiansystem.info `- Debian - when you have better things to do than fixing systems it is better to have loved a short man than never to have loved a tall. signature.asc Description: Digital signature (GPG/PGP)
Re: Time to rethink ifupdown
On Thursday 24 August 2006 09:58, Miles Bader wrote: martin f krafft [EMAIL PROTECTED] writes: Python (and any language that depends on vast amounts of installed infrastructure) seems a bit dodgy for a core low-level facility. It's a great language to develop stuff at a moderate speed. It may well be (kinda ugly though) -- but that doesn't mean it's appropriate for a core system facility, which often needs to work even when the system is in a degraded state. Remember also the Embedded Debian project, which produces code that works on very small machines with limited disk and memory. It would be shame to build something that they could not use. Many of these embedded systems do not have Python installed and would not have room to add it - even python-minimal. This kind of box is also probably the most likely to use complicated connection setups, they typically have multiple interfaces and are using them all at once. David -Miles -- `...the Soviet Union was sliding in to an economic collapse so comprehensive that in the end its factories produced not goods but bads: finished products less valuable than the raw materials they were made from.' [The Economist] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: debconf and substitution of non-translated text
Which can probably be worked around as La configuration du paquet «${pkg}» sera modifiée. or a similar construction, no? Absolutely. I actually changed the fr.po file in dbconfig-common SVN so that database fo ${pkg} which was translated to base de données de ${pkg} is now base de données pour ${pkg}...indeed a more literal translation which avoids the mentioned problem. Welcome to the French l10n team, Steve..:-) signature.asc Description: Digital signature
Re: debconf and substitution of non-translated text
On Thu, Aug 24, 2006 at 11:41:11AM +0200, Christian Perrier wrote: But, if pkg=apache, this becomes: La configuration de apache sera modifiée. While it should be: La configuration d'apache sera modifiée. True. But then, in most languages this can be worked around by using different phrase constructions. For example, the above could be formulated as La configuration du paquet ${pkg} sera modifiée. Which would get you rid of the inflection (if I'm not mistaken; my French has never been very good ;-) Of course, this is a workaround, not a fix. It'd be nice if debconf were to get ngettext, or something that works similar. Oh well. -- Lo-lan-do Home is where you have to wash the dishes. -- #debian-devel, Freenode, 2004-09-22 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#25837: my dream come true
Hi, Hope I am not writing to wronga aaddress. I am nice, pretty looking girl. I am planning on visiting your town this month. Can b we meet each aother in person? Message me back at [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: debconf and substitution of non-translated text
La configuration du paquet ${pkg} sera modifiée. Hoorray for the new member of the French l10n team:-) signature.asc Description: Digital signature
Re: These new diffs are great, but...
Florian Weimer [EMAIL PROTECTED] writes: * Goswin von Brederlow: However, patching rred to apply patches in a single run would be a good start because all further optimizations will need it. Why should the number of chunks matter? If you use the naïve algorithm, it does. But rred implements something more involved, leading to a O(patch-files * lines + changes) complexity (or something very similar). What matters is reading, parsing and writing the file O(lines) and then the number of changes (lines of changes) O(changes). Combined this gives O(lines + changes) if the file is read once at the start and then all patches are applied. I guess you'll find it very hard to get down to O(lines + changes). 8-) Either you need to make multiple passes over the original file (like the current code does), or you need to combine patch files before applying them. The latter involves some kind of sorting, and unless you postulate an upper bound on the number of lines in a file, you'll end up with super-linear complexity. Each change in the patches is an insert line, remove line or replace line. Thinking about it I see that insert/remove is a problem if you have an array of line pointers. But with a tree you can still insert/remove/replace each line in O(log lines) or O(changes * log lines) in total, which is better than O(lines * chunks). Or you do keep an array of line pointers and copy that for every chunk you process. Copying 50 pointers on every chunk doesn't sound too slow. The theoretical complexity would be O(lines * chunks) but the const factor should be way low. You can do that by combining the individual patch files or by teaching rred to do a single run with multiple patch files. Same result. Both solve the problem of O(lines * chunks + changes) complexity. The real problem is that APT's architecture doesn't allow rred to look at all patches at once. At least that's what I've been told. True. The apt methods aren't designed to process multiple files at once. You can't use something designed for gunziping a single file to combine multiple patches into a new Packages file. You have to design something new. As for using pointers to lines and shuffeling them that seems to be the only sane thing to do. All patch operations are line based so it is essential that a line can be found and replaced in O(1). A simple array of pointers to lines solves that. Inserting in the middle of an array is not a constant-time operation. That's why the naïve algorithm is slow. Yeah. I noticed that too now. As said above use a tree [O(log n) per operation] or copy the array [O(n) total per pass]. Copying a pointer to a line is better than copying each line since the hidden constant is way lower. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Running x86-64 debian inside i386 pbuilder on AMD64
Sander Marechal [EMAIL PROTECTED] writes: I am looking to create .deb's for x86-64. I have an AMD64 but run an i386 OS due to the lack of some 64-bit packages (like flash and what-not). I have pbuilder all set up to build packages for i386, but I wonder if it's possible to use it to create x86-64 packages as well. After all, I do have an AMD64 so I can run x86-64 packages. So, is it possible to bootstrap an x86-64 OS with pbuilder on an i386 system running on an AMD64? Yes, this should be possible (if you are running an amd64 kernel). I would try (not tested): pbuilder create --debootstrapopts --arch=amd64 Matthias -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dh_python and python policy analysis
Le mercredi 23 août 2006 à 15:39 +0300, Lars Wirzenius a écrit : The location is specific to the packaging tool and shouldn't be mentioned in the policy. Sure, that's fine: no need to mention it in policy. What was said earlier in the thread was that the locations should not be referenced in debian/rules, either, and that makes things difficult. This is the whole purpose of the dh_* snippets. -- .''`. Josselin Mouette/\./\ : :' : [EMAIL PROTECTED] `. `'[EMAIL PROTECTED] `- Debian GNU/Linux -- The power of freedom
Re: Running x86-64 debian inside i386 pbuilder on AMD64
Matthias Julius wrote: Sander Marechal [EMAIL PROTECTED] writes: I am looking to create .deb's for x86-64. I have an AMD64 but run an i386 OS due to the lack of some 64-bit packages (like flash and what-not). I have pbuilder all set up to build packages for i386, but I wonder if it's possible to use it to create x86-64 packages as well. After all, I do have an AMD64 so I can run x86-64 packages. So, is it possible to bootstrap an x86-64 OS with pbuilder on an i386 system running on an AMD64? Yes, this should be possible (if you are running an amd64 kernel). I would try (not tested): pbuilder create --debootstrapopts --arch=amd64 Nope, I run a K7 kernel now (Ubuntu dapper). Can I simply replace my kernel and leave the rest of my system in tact? I don't see AMD64 kernel images in Synaptic. Probably a silly question, but who knows :-) -- Sander Marechal http://www.gnome-hearts.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: glibc and UNACCEPTs
Hello! On Tue, 22 Aug 2006 20:51:56 +0200, David Nusinow wrote: On Tue, Aug 22, 2006 at 03:30:07PM -0400, Joey Hess wrote: Drew Parsons wrote: Unfortunately it's happened against, this time with the upload of xorg-server (xserver-xorg-core) 1:1.1.1-3, accidentally uploaded to unstable instead of experimental. An easy enough mistake, it's only one little field in a changelog file. '2:' is not any worse than '1:', so I don't see why this is any worse than any other bug that upload could have introduced. Upload again with a new epoch, problem solved. This is what I'd consider the appropriate fix. Just do another upload straight away and you don't even need to bother an ftpmaster. It's what I would have done if I'd been awake. Well, the problem is that with my daily `apt-get update apt-get upgrade` I got (again) the xserver-xorg from unstable, ending up with some X.Org packages from unstable and some from experimental, which AFAIK isn't a good thing :-( = [EMAIL PROTECTED]:~$ apt-cache policy xserver-xorg xserver-xorg: Installed: 1:7.0.23 Candidate: 1:7.0.23 Version table: *** 1:7.0.23 0 990 http://ftp.ch.debian.org unstable/main Packages 100 /var/lib/dpkg/status 1:7.0.22 0 500 http://ftp.ch.debian.org testing/main Packages [EMAIL PROTECTED]:~$ apt-cache policy xserver-xorg-core xserver-xorg-core: Installed: 2:1.0.2-10 Candidate: 2:1.0.2-10 Version table: *** 2:1.0.2-10 0 990 http://ftp.ch.debian.org unstable/main Packages 100 /var/lib/dpkg/status 1:1.1.1-2 0 1 http://ftp.ch.debian.org experimental/main Packages 1:1.0.2-9 0 500 http://ftp.ch.debian.org testing/main Packages [EMAIL PROTECTED]:~$ apt-cache policy xserver-xorg-input-mouse xserver-xorg-input-mouse: Installed: 1:1.1.1-2 Candidate: 1:1.1.1-2 Version table: *** 1:1.1.1-2 0 1 http://ftp.ch.debian.org experimental/main Packages 100 /var/lib/dpkg/status 1:1.0.4-3 0 500 http://ftp.ch.debian.org testing/main Packages 990 http://ftp.ch.debian.org unstable/main Packages [EMAIL PROTECTED]:~$ apt-cache policy xserver-xorg-video-v4l xserver-xorg-video-v4l: Installed: 0.1.1-1 Candidate: 0.1.1-1 Version table: *** 0.1.1-1 0 1 http://ftp.ch.debian.org experimental/main Packages 100 /var/lib/dpkg/status 0.0.1.5-1 0 500 http://ftp.ch.debian.org testing/main Packages 990 http://ftp.ch.debian.org unstable/main Packages [EMAIL PROTECTED]:~$ = I don't think it's my fault (not having preserved xserver-xorg-core From an upgrade), but in case of just disregard this post. If it's not my fault, however, I think we need a new package in experimental... Thx, bye, Gismo / Luca pgpsSVCYsxZT2.pgp Description: PGP signature
Re: dh_python and python policy analysis
to, 2006-08-24 kello 16:25 +0200, Josselin Mouette kirjoitti: Le mercredi 23 août 2006 à 15:39 +0300, Lars Wirzenius a écrit : The location is specific to the packaging tool and shouldn't be mentioned in the policy. Sure, that's fine: no need to mention it in policy. What was said earlier in the thread was that the locations should not be referenced in debian/rules, either, and that makes things difficult. This is the whole purpose of the dh_* snippets. Round and round we go. The people writing the dh_* snippets insist that the details of how they work, such as locations in which Python modules should actually be installed, can't be put into the Policy. The Policy editor, and those of use who don't want to use debhelper, insist that writing policy based on debhelper tools is not acceptable. This has now been going on for long enough that I conclude that the Python policy pushers really do intend to make using debhelper a Policy requirement for any package containing any Python code. -- On a clear disk, you seek forever. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#384476: lintian: please emit error for dependencies against python-minimal
Package: lintian Severity: wishlist * Steve Langasek [Thu, 24 Aug 2006 01:45:26 -0700]: On Thu, Aug 24, 2006 at 10:23:46AM +0200, Stefano Zacchiroli wrote: On Thu, Aug 24, 2006 at 08:43:22AM +0100, martin f krafft wrote: Also note that much of Debian started out as Perl. I won't compare the two, but it's basically the same. And there is python-minimal and I have heard rumours that it will be in base soon. What? What? What? Can you expand on this rumor (you or someone else)? I was postponing a post on debian-devel asking about having some sort of python in base since I developed a tool for managing vim add-ons in python, but I'm scared about uploading it with a dependency on python (since it should be shipped with vim itself). More generally we have core tools developed in python (e.g. reportbug), and it's a pity not having the minimal needed python support for them in base. Frankly, I think the fact that Debian has a python-minimal package at *all* is deplorable. When this package first snuck into Debian from Ubuntu, it was stated quite clearly in the following discussion that upstream considered it completely unacceptable for anyone to ship python in such a state that users would end up with less than the full python suite installed on their system. The *only* reason for the split between python and python-minimal in Ubuntu is because python-minimal is Essential: yes, and the only reason this split is *acceptable* to upstream is that python itself is also part of the base system (Priority: important). Given that there has been no decision to include python-minimal in the set of essential packages for Debian, and python hasn't been promoted to the base system for Debian, it's totally premature for this package to even exist in Debian. The only goal this package serves is to make it convenient for the maintainer to maintain the package for both Debian and Ubuntu from a single source; in all other respects, it's bad for Debian. And the python2.4-minimal package even has reverse-dependencies in unstable now. sigh It sounds to me like this is something lintian could check (it already does with other packages, see e.g. the depends-on-x-metapackage tag). Lintian maintainers, would you be willing to add a check to flag as an error any dependency against python*-minimal, based on the above explanation by Steve? -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org Kindness is a language which the deaf can hear and the blind can read. -- Mark Twain -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: glibc and UNACCEPTs
On Thu, 2006-08-24 at 16:51 +0200, Luca Capello wrote: If it's not my fault, however, I think we need a new package in experimental... Already uploaded. -- Earthling Michel Dänzer | http://tungstengraphics.com Libre software enthusiast | Debian, X and DRI developer
Re: Running x86-64 debian inside i386 pbuilder on AMD64
On 10756 March 1977, Sander Marechal wrote: Nope, I run a K7 kernel now (Ubuntu dapper). Can I simply replace my kernel and leave the rest of my system in tact? I don't see AMD64 kernel images in Synaptic. Probably a silly question, but who knows :-) You need to run dpkg with the right --force option to install a 64bit kernel with the wrong arch amd64 on your system. Works perfectly nice, but you should be sure your cpu is really able to run it, or next reboot doesnt get far. -- bye Joerg Christian bignachos: the famous pornview maintainer? HoserHead Christian: *don't* ask why he's typing so slowly bignachos hey, at least i thoroughly test my packages -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Running x86-64 debian inside i386 pbuilder on AMD64
Sander Marechal [EMAIL PROTECTED] writes: Nope, I run a K7 kernel now (Ubuntu dapper). Can I simply replace my kernel and leave the rest of my system in tact? I don't see AMD64 kernel images in Synaptic. Probably a silly question, but who knows :-) Not silly at all. There used to be such a package in sarge (i.e. a 64-bit kernel i386 package). Unfortunately, it doesn't now :-(. Ganesan -- Ganesan Rajagopal -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Why does Ubuntu have all the ideas?
Am 2006-07-28 12:43:55, schrieb John Goerzen: I like the fact that a base Debian install is only 100MB. Most of Debian's competitors are 10 times that. Ist now over 200 MByte... It was Woody with 64 MByte but a custom Sarge can striped to 92 MByte which would be interesting for Servers, routers and such... If you are eBay, and you absolutely must have your website up at all times, which do you care about? The latest kernel or the most stable one? Unfortunatly, eBay is running Microsof IIS version 4 and 5. This is, why eBay is inaccessible between 10:00 and 12:00 GMT. The MS SQL reqires a shutwown while Vacuumizing. I'd say that Debian's big wins aren't the number of packages it has. It's that the system is stable, well-designed, tightly integrated, and predictable. These are extremely valuable things. FullACK It's just that these users aren't a huge majority in Debian. Right I run Debian on laptops and desktops just fine. Me too: Toshiba T1950CT (486dx50, 12 MB, Woody), IBM TP760ED, IBM R40, IBM T72, ... My Desktop is running fvwm since I use Debian (Slink, 03/1999) and it had never failed. It's not that we can't relate to them. It's that you are asking Debian to alienate all of its other users in order to turn itself into Ubuntu. Let Ubuntu care about users that want Ubuntu and let Debian care about users that want Debian. FullACK The day Debian becomes the OS you want it to be is the day I switch to something else, because it will cease being a useful general purpose operating system. Note that I also believe that Windows is not a useful general purpose operating system. ;-) Greetings Michelle Konzack Systemadministrator Tamay Dogan Network Debian GNU/Linux Consultant -- Linux-User #280138 with the Linux Counter, http://counter.li.org/ # Debian GNU/Linux Consultant # Michelle Konzack Apt. 917 ICQ #328449886 50, rue de Soultz MSM LinuxMichi 0033/6/6192519367100 Strasbourg/France IRC #Debian (irc.icq.com) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Why does Ubuntu have all the ideas?
Hello Katrina, Am 2006-07-28 12:42:01, schrieb Katrina Jackson: PS. Hardware, Hardware, Hardware, I have to confess, if there was better hardware support I think most people would be happy. Hardware supported by Ubuntu 6 months ago, should be supported by Debian by now. Why do you try to blame Debian for the sucking Hardware support which is definitifly a thing of the Kernel (Linux) which depend on the support of the hardware manufacturer. If you want to get better hardware support, please contact the manufacturer. Note: I am using since MANY years IBM Laptops (760ED, R40, T72) and I have never had problems to get it running since Debian 2.2 codename Potato. Greetings Michelle Konzack Systemadministrator Tamay Dogan Network Debian GNU/Linux Consultant -- Linux-User #280138 with the Linux Counter, http://counter.li.org/ # Debian GNU/Linux Consultant # Michelle Konzack Apt. 917 ICQ #328449886 50, rue de Soultz MSM LinuxMichi 0033/6/6192519367100 Strasbourg/France IRC #Debian (irc.icq.com) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Why does Ubuntu have all the ideas?
Am 2006-07-28 13:35:30, schrieb Katrina Jackson: You say Ubuntu has better publicity, which it does. But why is this the case? I know Mark has more money, but since you have so many programmers, He is Miliardaire (TV interview and his own words). and seem so passionate about your OS, why aren't you as successful getting publicity? I'm not accusing anyone. I guess I just really would like to know: Do we need publicity of tens of million Euros? A.) Could Debian do anything to get better publicity and change people's perceptions. (For instance, if Debian is so more well build then Ubuntu why don't the press keep mentioning this? Do you want to pay the making of such publicity? Ubuntu/Canonical is commercial while Debian is a volunter organization. B.) Why hasn't more been done? Why isn't there any major reports by like PC World which say Ubuntu is top 100 products, but man if you want a better distro, more well built etc.. you should check out Debian. Because Ubunto pay for ranking? ;-) Greetings Michelle Konzack Systemadministrator Tamay Dogan Network Debian GNU/Linux Consultant -- Linux-User #280138 with the Linux Counter, http://counter.li.org/ # Debian GNU/Linux Consultant # Michelle Konzack Apt. 917 ICQ #328449886 50, rue de Soultz MSM LinuxMichi 0033/6/6192519367100 Strasbourg/France IRC #Debian (irc.icq.com) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Running x86-64 debian inside i386 pbuilder on AMD64
Joerg Jaspert wrote: On 10756 March 1977, Sander Marechal wrote: Nope, I run a K7 kernel now (Ubuntu dapper). Can I simply replace my kernel and leave the rest of my system in tact? I don't see AMD64 kernel images in Synaptic. Probably a silly question, but who knows :-) You need to run dpkg with the right --force option to install a 64bit kernel with the wrong arch amd64 on your system. Works perfectly nice, but you should be sure your cpu is really able to run it, or next reboot doesnt get far. I'm sure allright. I've had various 64 bit distro's on this machine, but lack of flash and a few other 32-bit only things always make me go back. Quick question: Do I only need the AMD64 linux-image package, or also the linux-restricted-modules package? Thanks, -- Sander Marechal http://www.gnome-hearts.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#384474: ITP: weplab -- tool designed to break WEP keys
Package: wnpp Severity: wishlist Owner: Adam Cécile (Le_Vert) [EMAIL PROTECTED] -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 * Package name: weplab Version : 0.1.5 Upstream Author : Jose Ignacio Sanchez [EMAIL PROTECTED] * URL : http://weplab.sourceforge.net/ * License : GPL Programming Lang: C Description : tool designed to break WEP keys WepLab is a tool designed to teach how WEP works, what different vulnerabilities it has, and how they can be used in practice to break a WEP protected wireless network. .. Homepage: http://weplab.sourceforge.net/ The package is ready and will be uploaded to mentors.debian.net soon ! - -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (900, 'testing'), (300, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.16-2-686-smp Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQFE7bhAHNb/igTI5bsRAurHAJwK1NOyHVaSMm8O3iYnX5aZrx6EBQCeLr7l TsajEVHstoUVm2iO2LRoW1o= =6f/A -END PGP SIGNATURE-
Re: Why does Ubuntu have all the ideas?
On Wed, Aug 23, 2006 at 12:05:53PM +0200, Michelle Konzack wrote: Am 2006-07-28 12:43:55, schrieb John Goerzen: I like the fact that a base Debian install is only 100MB. Most of Debian's competitors are 10 times that. Ist now over 200 MByte... No. I've been doing a ton of etch installs with cdebootstrap lately, and it's still just under 100MB. 97 or so if memory serves. A ton better than the RHEL/CentOS situation, where the stripped-down server install is over 1GB. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Why does Ubuntu have all the ideas?
Michelle Konzack wrote: Hello Katrina, Am 2006-07-28 12:42:01, schrieb Katrina Jackson: PS. Hardware, Hardware, Hardware, I have to confess, if there was better hardware support I think most people would be happy. Hardware supported by Ubuntu 6 months ago, should be supported by Debian by now. Why do you try to blame Debian for the sucking Hardware support which is definitifly a thing of the Kernel (Linux) which depend on the support of the hardware manufacturer. If you want to get better hardware support, please contact the manufacturer. Because, hardware support seems to be better in Ubutuntu than in Debian? I've not tested it by myself, but I've heard from many people claiming that their hardware (especially Laptop hardware) works perfectly out of the box with Ubuntu but is a PITA to get working on Debian. Note: I am using since MANY years IBM Laptops (760ED, R40, T72) and I have never had problems to get it running since Debian 2.2 codename Potato. Err, thanks for this useful background info. Hope you know that IBM is not the only company building laptops... Cheers, Bastian -- Bastian Venthur http://venthur.de -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dh_python and python policy analysis
On Thu, Aug 24, 2006 at 05:56:07PM +0300, Lars Wirzenius wrote: installed, can't be put into the Policy. The Policy editor, and those of use who don't want to use debhelper, insist that writing policy based on debhelper tools is not acceptable. Not just those who don't want to use debhelper. Policy is, and has always been, written in terms of how dpkg works. Nothing more. It would be a very bad idea to change that, if only because somebody might have a nice idea for a build tool that would supersede debhelper. While it is, IMHO, perfectly acceptable to insist that people use some debhelper tool if they want to package something pythonesque, it is not acceptable to not document how they are *supposed* to work. -- Lo-lan-do Home is where you have to wash the dishes. -- #debian-devel, Freenode, 2004-09-22 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#384476: lintian: please emit error for dependencies against python-minimal
Adeodato Simó [EMAIL PROTECTED] writes: Lintian maintainers, would you be willing to add a check to flag as an error any dependency against python*-minimal, based on the above explanation by Steve? We already did for python-minimal. I've expanded that check for the next release of lintian to include versioned variants as well. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/
Re: Why does Ubuntu have all the ideas?
On Thu, Aug 24, 2006 at 06:16:49PM +0200, Bastian Venthur wrote: which is definitifly a thing of the Kernel (Linux) which depend on the support of the hardware manufacturer. If you want to get better hardware support, please contact the manufacturer. Because, hardware support seems to be better in Ubutuntu than in Debian? I've not tested it by myself, but I've heard from many people claiming that their hardware (especially Laptop hardware) works perfectly out of the box with Ubuntu but is a PITA to get working on Debian. This sort of vague anecdotal evidence has been repeated over and over. It may be true, but as far as I know, nobody has yet to come forth with reporting specific problems in Debian, only x worked out of the box in ubuntu but not in Debian. Well, that may be, but that's not necessarily a bug in Debian. For instance, for many years, the Debian installer did not support LVM, even though the Debian OS did. Is that a bug (in the classic sense) in the Debian installer? I'd say no, it was just a feature it didn't have. We ship a lot of modules as source in Debian -- lirc, for instance, but you can also find source modules for things like nvidia in contrib or non-free. Building binaries from source modules is trivial but non-obvious to someone that is not a Linux admin. Perhaps that could be improved, but it doesn't mean that Debian supports less hardware, only that its support may appear in a different manner. (I haven't used Ubuntu, so I don't know if this is the problem or not) BTW, there is a strong case to be made that Debian supports far more hardware than Ubuntu simply because ports of Ubuntu are sadly deficient. That is one reason I have never turned to Ubuntu. I can't run it on my Alpha, I couldn't have run it on my Zaurus (arm) like I did with Debian, etc. Hardware choice is important to me. I don't want my software selection to lock me into one or two hardware platforms -- I want to be able to buy an Arm, Sparc, Alpha, PowerPC, or whatever device and put my chosen software on it if I so desire. So it all depends on your perspective. If you narrow your perspective to ia32 laptop hardware, perhaps Ubuntu supports more. If you expand it, I would say Debian supports more. -- John -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Why does Ubuntu have all the ideas?
John Goerzen wrote: On Thu, Aug 24, 2006 at 06:16:49PM +0200, Bastian Venthur wrote: which is definitifly a thing of the Kernel (Linux) which depend on the support of the hardware manufacturer. If you want to get better hardware support, please contact the manufacturer. Because, hardware support seems to be better in Ubutuntu than in Debian? I've not tested it by myself, but I've heard from many people claiming that their hardware (especially Laptop hardware) works perfectly out of the box with Ubuntu but is a PITA to get working on Debian. So it all depends on your perspective. If you narrow your perspective to ia32 laptop hardware, perhaps Ubuntu supports more. If you expand it, I would say Debian supports more. I absolutely agree with you, off course Debian supports more hardware than Ubuntu. But that was not the point, Michelle claimed that hardware support depends entirely on the kernel, which is IMHO only one half of the truth. The end user usually understands under hardware support, how well the system recognizes hardware and it's ability to get it working with a minimum of user interaction required. And from what I've heard Ubuntu seems to be ahead of Debian at this point. Again, I never used Ubuntu myself, but some friends of mine did, and they claim Ubuntu has the best hardware support of all distros they tested (mostly Suse and Debian). Cheers, Bastian -- Bastian Venthur http://venthur.de -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#384474: ITP: weplab -- tool designed to break WEP keys
Am Donnerstag 24 August 2006 16:31 schrieb Adam Cécile: Description : tool designed to break WEP keys It is legal to ship a tool like that in all countries? Same question goes for airsnort, I guess. HS
Re: Time to rethink ifupdown
On Thu, 24 Aug 2006 08:43:22 +0100, martin f krafft [EMAIL PROTECTED] said: also sprach Miles Bader [EMAIL PROTECTED] [2006.08.24.0334 +0100]: Python (and any language that depends on vast amounts of installed infrastructure) seems a bit dodgy for a core low-level facility. It's a great language to develop stuff at a moderate speed. Also note that much of Debian started out as Perl. I won't compare the two, but it's basically the same. And there is python-minimal and I have heard rumours that it will be in base soon. If we were starting out from scratch, sure, there would be little difference -- but we already have a minimal Perl essential package, and I am not sure bloating the minimal install with yet another scripting language is a good idea. If we are gonna be doing so, however, ruby is a better scripting language to add to base. Personally, I tink adding ayet another language would be a mistake, though. manoj -- Ever wonder if taxation without representation might have been cheaper? Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Why does Ubuntu have all the ideas?
On Thu, Aug 24, 2006 at 07:29:22PM +0200, Bastian Venthur wrote: John Goerzen wrote: On Thu, Aug 24, 2006 at 06:16:49PM +0200, Bastian Venthur wrote: which is definitifly a thing of the Kernel (Linux) which depend on the support of the hardware manufacturer. If you want to get better hardware support, please contact the manufacturer. Because, hardware support seems to be better in Ubutuntu than in Debian? I've not tested it by myself, but I've heard from many people claiming that their hardware (especially Laptop hardware) works perfectly out of the box with Ubuntu but is a PITA to get working on Debian. So it all depends on your perspective. If you narrow your perspective to ia32 laptop hardware, perhaps Ubuntu supports more. If you expand it, I would say Debian supports more. I absolutely agree with you, off course Debian supports more hardware than Ubuntu. But that was not the point, Michelle claimed that hardware support depends entirely on the kernel, which is IMHO only one half of the truth. The end user usually understands under hardware support, how well the system recognizes hardware and it's ability to get it working with a minimum of user interaction required. And from what I've heard Ubuntu seems to be ahead of Debian at this point. My personal opinion about Ubuntu stable vs Debian stable: * newer kernels * nearly completely untested In other words, Ubuntu _is_ ahead of Debian, both in the positive and negative sense. It releases a lot more often, so it obviously features more recent kernels. On the other hand, Ubuntu strongly suffers from the tendency to include all the newest unstable doodads, so the path: Ubuntu - experimental - unstable - stable is trodden often these days. In the term of hardware drivers, people put very little effort into stabilizing them once they appear to be working, so for ia32 hardware coverage, Ubuntu does fare better on the average. This doesn't excuse them from shipping buggy drivers, which they do. You can choose between a stable, solid distribution that lacks the newest trinkets and something on the cutting edges that explodes at touch. Testing things takes time, and this is exactly what Debian does. Is the choice between Debian and Ubuntu a bad thing? -- 1KB // Microsoft corollary to Hanlon's razor: // Never attribute to stupidity what can be // adequately explained by malice. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#384496: ITP: luafilesystem -- filesystem library to the lua language
Package: wnpp Severity: wishlist Owner: Enrico Tassi [EMAIL PROTECTED] * Package name: luaexpat Version : 1.0.2 Upstream Author : oberto Ierusalimschy, André Carregal and Tomás Guisasola as part of the Kepler Project [EMAIL PROTECTED] * URL : http://www.keplerproject.org/luafilesystem/ * License : MIT/X Programming Lang: C, lua Description : filesystem library to the lua language This library includes simple facilities (not ansi C, thus not included in the lua standard library) like directory listing and file locking. Here you can find a tentative package: http://svn.debian.org/wsvn/pkg-lua/packages/luafilesystem/?rev=0sc=0 -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.17-1-amd64-k8 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Re: Running x86-64 debian inside i386 pbuilder on AMD64
Sander Marechal [EMAIL PROTECTED] writes: Quick question: Do I only need the AMD64 linux-image package, or also the linux-restricted-modules package? You need corresponding versions of whichever modules package(s) you currently have installed. -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) Finger [EMAIL PROTECTED] (NOT a valid e-mail address) for more info. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Running x86-64 debian inside i386 pbuilder on AMD64
Aaron M. Ucko wrote: Sander Marechal [EMAIL PROTECTED] writes: Quick question: Do I only need the AMD64 linux-image package, or also the linux-restricted-modules package? You need corresponding versions of whichever modules package(s) you currently have installed. Thanks. The kernel works but I loose the nvidia driver and with it XGL, so X crashes on startup (I have the XGL server replace the standard X server, not run on top of it). What is the normal way to build amd64 .deb's on a 32-bit debian/ubuntu? -- Sander Marechal http://www.gnome-hearts.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Why does Ubuntu have all the ideas?
Aaron M. Ucko wrote: Sander Marechal [EMAIL PROTECTED] writes: I don't think Debian should do that, but perhaps the process to install them after the fact could be easier for people who are not full blown Linux admins? Are you aware of module-assistant? Nope, but I was going off Bastian's comment that a lot of modules get shipped as source and need to be compiled. I use Ubuntu myself (plain Debian as a dev system and test system) so I already have the modules I need. -- Sander Marechal http://www.gnome-hearts.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Why does Ubuntu have all the ideas?
Aaron M. Ucko wrote: Sander Marechal [EMAIL PROTECTED] writes: I don't think Debian should do that, but perhaps the process to install them after the fact could be easier for people who are not full blown Linux admins? Are you aware of module-assistant? module-assistant is cool, if you know that it exists (which you can't assume for the average user, i think) and have the guts to actually use it :) But since you mention it, module-assistant is a good example for the hardware support thing I mentioned before: it might not sound too complicated for us to re-run it every time aptitude bumped our kernel versions, but I think the average user, expects something like his to happen automatically. Cheers, Bastian -- Bastian Venthur http://venthur.de -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#384519: ITP: gaffitter -- file subsets extractor based on genetic algorithms
Package: wnpp Severity: wishlist Owner: Nacho Barrientos Arias [EMAIL PROTECTED] * Package name: gaffitter Version : 0.4.2 Upstream Author : Douglas A. Augusto [EMAIL PROTECTED] * URL : http://gaffitter.sourceforge.net/ * License : GPL Programming Lang: C++ Description : file subsets extractor based on genetic algorithms Genetic Algorithm File Fitter (gaffitter) is a command-line software written in C++ that extracts --via genetic algorithm-- subsets of an input list of files/directories that best fit the given volume size (target), such as CD, DVD and others. gaffitter provides an intelligent manner (thanks to Genetic Algorithm) to minimize the error between the desired target size and the selected candidates of files/directories. gaffitter highlights: - Uses a global meta-heuristic (Genetic Algorithm search). - The command-line interface provides high integration (via pipe) with other tools, i.e. works as a filter. - Allow the user to enter 'size identifier' pairs directly instead of file/dir names. - Pretty configurable. gaffitter have many input parameters to control/adjust its behavior (including GA params). -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.17.1 Locale: LANG=en_GB.ISO-8859-15, LC_CTYPE=en_GB.ISO-8859-15 (charmap=ISO-8859-15) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dh_python and python policy analysis
Le jeudi 24 août 2006 à 17:56 +0300, Lars Wirzenius a écrit : Round and round we go. The people writing the dh_* snippets insist that the details of how they work, such as locations in which Python modules should actually be installed, can't be put into the Policy. The Policy editor, and those of use who don't want to use debhelper, insist that writing policy based on debhelper tools is not acceptable. Let me rephrase it: the internals of python-support, and how it helps implementing the python policy, are developed in the python-support documentation. They don't need to be part of the policy and they have nothing to do with debhelper either. This has now been going on for long enough that I conclude that the Python policy pushers really do intend to make using debhelper a Policy requirement for any package containing any Python code. I can't speak for others, but python-support provides pysupport-movemodules and pysupport-parseversions to separate the debhelper snippet from the actual abstraction code. (BTW, for a similar problematic that involves more than a hundred packages, nobody ever asked me how to make a package using GConf without using dh_gconf. Which means the GConf policy has never been written out but is currently defined by the dh_gconf behavior.) -- .''`. Josselin Mouette/\./\ : :' : [EMAIL PROTECTED] `. `'[EMAIL PROTECTED] `- Debian GNU/Linux -- The power of freedom signature.asc Description: Ceci est une partie de message numériquement signée
Re: Why does Ubuntu have all the ideas?
Sander Marechal [EMAIL PROTECTED] writes: I don't think Debian should do that, but perhaps the process to install them after the fact could be easier for people who are not full blown Linux admins? Are you aware of module-assistant? -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) Finger [EMAIL PROTECTED] (NOT a valid e-mail address) for more info. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Running x86-64 debian inside i386 pbuilder on AMD64
Sander Marechal [EMAIL PROTECTED] writes: Thanks. The kernel works but I loose the nvidia driver and with it XGL, so X crashes on startup (I have the XGL server replace the standard X server, not run on top of it). Maybe you just need to rebuild the nVidia kernel modules? Matthias -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Why does Ubuntu have all the ideas?
Bastian Venthur wrote: Michelle Konzack wrote: Hello Katrina, Am 2006-07-28 12:42:01, schrieb Katrina Jackson: PS. Hardware, Hardware, Hardware, I have to confess, if there was better hardware support I think most people would be happy. Hardware supported by Ubuntu 6 months ago, should be supported by Debian by now. Why do you try to blame Debian for the sucking Hardware support which is definitifly a thing of the Kernel (Linux) which depend on the support of the hardware manufacturer. If you want to get better hardware support, please contact the manufacturer. Because, hardware support seems to be better in Ubutuntu than in Debian? I've not tested it by myself, but I've heard from many people claiming that their hardware (especially Laptop hardware) works perfectly out of the box with Ubuntu but is a PITA to get working on Debian. Ubuntu ships with some restricted modules for better hardware support. To be exact (from synaptic): - madwifi (Atheros) - fglrx (ATI) - nvidia - fcdsl2, fcdslsl, fcdslslusb, fcdslusb, fcdslusb2, fcpci, fcpcmcia, fcpcmcia_cs (AVM ISDN) I don't think Debian should do that, but perhaps the process to install them after the fact could be easier for people who are not full blown Linux admins? -- Sander Marechal http://www.gnome-hearts.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Why does Ubuntu have all the ideas?
Sander Marechal [EMAIL PROTECTED] writes: Aaron M. Ucko wrote: Sander Marechal [EMAIL PROTECTED] writes: I don't think Debian should do that, but perhaps the process to install them after the fact could be easier for people who are not full blown Linux admins? Are you aware of module-assistant? Nope, but I was going off Bastian's comment that a lot of modules get shipped as source and need to be compiled. I use Ubuntu myself (plain Debian as a dev system and test system) so I already have the modules I need. Note that Ubuntu doesn't build all the kernel modules either; Ubuntu users have to build their own kernel modules for OpenAFS, for instance, just like Debian users do. We really need to put our heads together and come up with a good system for managing pre-built kernel modules for the kernels in Debian. It's a much more widespread problem than just a question of free vs. non-free. It's possible to do right now, but it involves a ton of manual work by the maintainer every time the list of officially supported kernels changes, and pretty much every upload goes through NEW. I think that to have a really good solution, we're going to need a larger plan that includes changes to the archive management software as well. I'd love to see this be a priority for etch+1. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#384496: ITP: luafilesystem -- filesystem library to the lua language
Am Donnerstag 24 August 2006 19:19 schrieb Enrico Tassi: Package: wnpp Severity: wishlist Owner: Enrico Tassi [EMAIL PROTECTED] * Package name: luaexpat Somehow, that doesn't match the rest. HS -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
32 bit chroot and ld-linux.so.2
I'm installing a 32 bit chroot, following http://www.debian-administration.org/articles/356 First, there is a tiny typo under 1.2 -arch should be --arch Second, it says that I have to put a soft link in /lib to the ld-linux.so.2 in the chroot. My question is, given that I already have a ld-linux.so.2 in /lib, why do I need the link? Art Edwards -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Why does Ubuntu have all the ideas?
Em Quinta 24 Agosto 2006 18:08, Bastian Venthur escreveu: Hi! Aaron M. Ucko wrote: Sander Marechal [EMAIL PROTECTED] writes: I don't think Debian should do that, but perhaps the process to install them after the fact could be easier for people who are not full blown Linux admins? Are you aware of module-assistant? module-assistant is cool, if you know that it exists (which you can't assume for the average user, i think) and have the guts to actually use it :) But since you mention it, module-assistant is a good example for the hardware support thing I mentioned before: it might not sound too complicated for us to re-run it every time aptitude bumped our kernel versions, but I think the average user, expects something like his to happen automatically. I'm really a noob when it comes to the kernel guts, but i wonder, can't it be made like updating /boot/grub/menu.lst with a new kernel version ? -- YUP! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Why does Ubuntu have all the ideas?
On Thu, Aug 24, 2006 at 07:26:04PM -0300, Fabricio aybabtu Cannini wrote: I'm really a noob when it comes to the kernel guts, but i wonder, can't it be made like updating /boot/grub/menu.lst with a new kernel version ? Yes, you could in theory compile a kernel module package from another package's postinst, but: 1. You would have to guarantee the right kernel headers are installed at the time. (You can't install them either, see the next point.) 2. You cannot install it, as you can't call dpkg from a postinst script, and dpkg does not yet have any “trigger” functionality that would run afterwards. /* Steinar */ -- Homepage: http://www.sesse.net/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Why does Ubuntu have all the ideas?
El día 24/08/2006 a 11:25 Michelle Konzack escribió... Am 2006-07-28 13:35:30, schrieb Katrina Jackson: You say Ubuntu has better publicity, which it does. But why is this the case? I know Mark has more money, but since you have so many programmers, He is Miliardaire (TV interview and his own words). and seem so passionate about your OS, why aren't you as successful getting publicity? I'm not accusing anyone. I guess I just really would like to know: Do we need publicity of tens of million Euros? A.) Could Debian do anything to get better publicity and change people's perceptions. (For instance, if Debian is so more well build then Ubuntu why don't the press keep mentioning this? Do you want to pay the making of such publicity? Ubuntu/Canonical is commercial while Debian is a volunter organization. I do believe it's more a matter of relations with press and media than budget. We have no easy-way-to-get-it to tell people why they would want to use Debian. Ubuntu, on the other hand, has achieved to do so, and what they tell that we can't? nothing. All what they advertise we do offer. But we are not good on advertise our OS. We need to tell people: Debian is fine for you because it allows you to get your work done and be productive, whether you are an artist, corporate employee, student, doctor, etc. (I didn't mention computer savy people since we are well known there, so why advertise for them, if we have an important market share on that segment?). That kind of advertisement, focusing on things that matter for people more than specs and technical details, which are only interesting for those who already in the computing area. I know there is a subproject working on such things, which is great. B.) Why hasn't more been done? Why isn't there any major reports by like PC World which say Ubuntu is top 100 products, but man if you want a better distro, more well built etc.. you should check out Debian. Because Ubunto pay for ranking? ;-) No, I still believe we need more people and relations with press, and not only the technical ones, we should advertise more our work and good experiences like donzka, LinEx, and the others. Not only tell ourselves: we know we are doing things better. We should tell it to others too! regards -- Rudy Godoy | 0x3433BD21 | http://stone-head.org ,''`. http://www.apesol.org - http://www.debian.org : :' : GPG FP: 0D12 8537 607E 2DF5 4EFB 35A7 550F 1A00 3433 BD21 `. `' `- signature.asc Description: Digital signature
Re: Why does Ubuntu have all the ideas?
Em Quinta 24 Agosto 2006 19:37, Steinar H. Gunderson escreveu: On Thu, Aug 24, 2006 at 07:26:04PM -0300, Fabricio aybabtu Cannini wrote: I'm really a noob when it comes to the kernel guts, but i wonder, can't it be made like updating /boot/grub/menu.lst with a new kernel version ? Yes, you could in theory compile a kernel module package from another package's postinst, but: Perhaps using dependencies or /etc/apt/preferences ? 1. You would have to guarantee the right kernel headers are installed at the time. (You can't install them either, see the next point.) 2. You cannot install it, as you can't call dpkg from a postinst script, and dpkg does not yet have any “trigger” functionality that would run afterwards. Like, if you have a -src package, can't you determinate that the kernel to be installed will work with it by dependencies ? ( in this case matching the exact kernel headers|source version ) -- YUP!
Bug#384533: ITP: gnome-main-menu - menu applet for GNOME
Package: wnpp Severity: wishlist X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: gnome-main-menu Version : 0.6.2 Upstream Author : Dan Winship, Jim Krehl, JP Rosevear, Scott Reeves (Novell) * URL : No website. Included in Gnome CVS * License : GPL/LGPL Programming Lang: C Description : menu applet for GNOME Long description still to be written. gnome-main-menu (also known as slab) is the replacement for the GNOME Main menu that got first included in Suse Linux Desktop 10. It features a favorite applications list, a full list of applications with search, integration with Beagle, and with Network-Manager for network status reporting. http://shots.osdir.com/slideshows/slideshow.php?release=700slide=5 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Why does Ubuntu have all the ideas?
Steinar H Gunderson [EMAIL PROTECTED] writes: On Thu, Aug 24, 2006 at 07:26:04PM -0300, Fabricio aybabtu Cannini wrote: I'm really a noob when it comes to the kernel guts, but i wonder, can't it be made like updating /boot/grub/menu.lst with a new kernel version ? Yes, you could in theory compile a kernel module package from another package's postinst, but: 1. You would have to guarantee the right kernel headers are installed at the time. (You can't install them either, see the next point.) 2. You cannot install it, as you can't call dpkg from a postinst script, and dpkg does not yet have any “trigger” functionality that would run afterwards. There's a more fundamental problem here, which is that we're not Gentoo. There's no reason why a Debian system should have to have a compiler installed. We have buildd farms to do that work for our users. I'd really like to find a way where that applies to kernel modules as well without the pain that we have right now. Unfortunately, while I appreciate people working on this problem, creating a combined package of out-of-tree kernel modules isn't really a solution. Some out-of-tree kernel modules are large and complex and can't easily just be dropped into that sort of shared tree. What we need is some way of correctly expressing the kernel module class of packages in the archive software, with automatic removal of packages for old versions of the kernel, automatic auto-building of the source package against new versions of the kernel when they appear (and new variants), and a way of handling those packages that doesn't mean source changes and a trip through NEW every time the list of kernel variants changes. This isn't easy, which is why it hasn't been done yet, but it's really the right approach. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#384545: ITP: keytouch-editor -- create or modify keyboard mappings for keytouch
Package: wnpp Severity: wishlist Owner: Luis Rodrigo Gallardo Cruz [EMAIL PROTECTED] Package name: keytouch-editor Version : 2.1.0 Upstream Author : Marvin Raaijmakers [EMAIL PROTECTED] URL : http://keytouch.sourceforge.net/index.html License : GPL Programming Lang: C Description : create or modify keyboard mappings for keytouch keytouch-editor allows you to define keyboard mappings for keyboards not yet supported by keytouch. keytouch-editor 2.1.0 is already packaged for Ubuntu. Said packaging will be used as a starting point for the Debian package. -- Rodrigo Gallardo GPG-Fingerprint: 7C81 E60C 442E 8FBC D975 2F49 0199 8318 ADC9 BC28 signature.asc Description: Digital signature
Re: dh_python and python policy analysis
On Thu, 24 Aug 2006 23:46:25 +0200, Josselin Mouette [EMAIL PROTECTED] said: Le jeudi 24 août 2006 à 17:56 +0300, Lars Wirzenius a écrit : Round and round we go. The people writing the dh_* snippets insist that the details of how they work, such as locations in which Python modules should actually be installed, can't be put into the Policy. The Policy editor, and those of use who don't want to use debhelper, insist that writing policy based on debhelper tools is not acceptable. Let me rephrase it: the internals of python-support, and how it helps implementing the python policy, are developed in the python-support documentation. They don't need to be part of the policy and they have nothing to do with debhelper either. This has now been going on for long enough that I conclude that the Python policy pushers really do intend to make using debhelper a Policy requirement for any package containing any Python code. I can't speak for others, but python-support provides pysupport-movemodules and pysupport-parseversions to separate the debhelper snippet from the actual abstraction code. I don't like adding unnecessary build dependencies for my packages. (BTW, for a similar problematic that involves more than a hundred packages, nobody ever asked me how to make a package using GConf without using dh_gconf. Which means the GConf policy has never been written out but is currently defined by the dh_gconf behavior.) Oh, all this means is that I havge not yet had any occassion to package Gnome stuff :) manoj -- There is nothing wrong with Southern California that a rise in the ocean level wouldn't cure. -- Ross MacDonald Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Running x86-64 debian inside i386 pbuilder on AMD64
Matthias Julius wrote: Sander Marechal [EMAIL PROTECTED] writes: So, is it possible to bootstrap an x86-64 OS with pbuilder on an i386 system running on an AMD64? Yes, this should be possible (if you are running an amd64 kernel). I would try (not tested): pbuilder create --debootstrapopts --arch=amd64 It didn't work after all. I got a kernel running, but debootstrap doesn't want to cooperate. It quits with an error that it cannot find a script. It takes a random string from the pbuilder configuration and tries lo look for a script at that place instead of /usr/lib/pbuilder/scripts. Weird. I think I'm going to take the easy way out and install a minimal dapper 64 in a small partition and use that to build amd64 binaries. -- Sander Marechal http://www.gnome-hearts.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: glibc and UNACCEPTs
Em Tue, 22 Aug 2006 23:47:09 -0300 Otavio Salvador [EMAIL PROTECTED] escreveu: Drew Parsons [EMAIL PROTECTED] writes: e.g. build: test_stable patch build-stamp instead of build: patch build-stamp That would be good to be add in cdbs. I think we might want to have it more flexible to allow it to work for CDDs too but I liked it very much :-D It does not look right to me, though.. what about buildds? And what about people forgetting an exported variable saying yes? I much rather the manual solution, or a solution for dak that detects that the target distribution changed and requests a confirmation by signed email, for instance. See you, -- Gustavo Noronha Silva [EMAIL PROTECTED] http://people.debian.org/~kov/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted capi4hylafax 1:01.03.00.99.svn.300-1 (source sparc)
-BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 Format: 1.7 Date: Wed, 23 Aug 2006 23:15:32 +0200 Source: capi4hylafax Binary: capi4hylafax Architecture: source sparc Version: 1:01.03.00.99.svn.300-1 Distribution: unstable Urgency: high Maintainer: Lionel Elie Mamane [EMAIL PROTECTED] Changed-By: Lionel Elie Mamane [EMAIL PROTECTED] Description: capi4hylafax - Faxing over CAPI 2.0 device Closes: 382474 Changes: capi4hylafax (1:01.03.00.99.svn.300-1) unstable; urgency=low . * New upstream release: - Fix for #358567 taken upstream - Fix for long ( 200 chars) lines in config files - Higher debbugging level * Bumped up Standards-Version . capi4hylafax (1:01.03.00.99.svn.297-4) UNRELEASED; urgency=high . * Don't let null characters from cidnumber prematurely terminate C string preparing command line for faxrcvd in c2faxrecv (closes: #382474). Also remove shell metacharacters while I'm at it. This probably fixes a security vulnerability (arbitrary remote command execution under uucp identity): the said command line contains untrusted sender-controlled data, the sender's identification (the TSI string). (The ITU T.30 specification restricts this string to a prefix '+' and digits only, but rumour has it an attacker can transmit arbitrary ASCII data, including null characters.) Files: dc7276e8c3b28efb084af14225565144 708 comm extra capi4hylafax_01.03.00.99.svn.300-1.dsc af2610c5219e89ef9dc47eead30276b4 533410 comm extra capi4hylafax_01.03.00.99.svn.300.orig.tar.gz 964e9a7c78dea6b6e681bddf18b6cc99 153873 comm extra capi4hylafax_01.03.00.99.svn.300-1.diff.gz da0d046449d1772bd9dc14316a60bf51 227218 comm extra capi4hylafax_01.03.00.99.svn.300-1_sparc.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) iEYEAREDAAYFAkTtQ4EACgkQscRzFz57S3OrHQCdF8mCckblBv6dMSos6cij6GV4 DIgAoJizTNXTwhiLeUQcpXL9YOHFpWLx =0HKh -END PGP SIGNATURE- Accepted: capi4hylafax_01.03.00.99.svn.300-1.diff.gz to pool/main/c/capi4hylafax/capi4hylafax_01.03.00.99.svn.300-1.diff.gz capi4hylafax_01.03.00.99.svn.300-1.dsc to pool/main/c/capi4hylafax/capi4hylafax_01.03.00.99.svn.300-1.dsc capi4hylafax_01.03.00.99.svn.300-1_sparc.deb to pool/main/c/capi4hylafax/capi4hylafax_01.03.00.99.svn.300-1_sparc.deb capi4hylafax_01.03.00.99.svn.300.orig.tar.gz to pool/main/c/capi4hylafax/capi4hylafax_01.03.00.99.svn.300.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted streamripper 1.61.25-2 (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Sun, 20 Aug 2006 14:25:39 +0200 Source: streamripper Binary: streamripper Architecture: source i386 Version: 1.61.25-2 Distribution: unstable Urgency: high Maintainer: Michael Ablassmeier [EMAIL PROTECTED] Changed-By: Michael Ablassmeier [EMAIL PROTECTED] Description: streamripper - download online streams into audio files Changes: streamripper (1.61.25-2) unstable; urgency=high . * Use simple-patchsys.mk: + Add 01_CVE-2006-3124.patch: Fix for remote buffer overflow discovered by Ulf Harnhammar (CVE-2006-3124). Files: fc539cf028467cf0ded752c9add15431 652 sound optional streamripper_1.61.25-2.dsc b367f0be17d74ac683577f27f0fbb801 3824 sound optional streamripper_1.61.25-2.diff.gz e7717968442658ea6b3e26184c0b5f28 70636 sound optional streamripper_1.61.25-2_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQFE6FibEFV7g4B8rCURAmJlAJwI0oA00HlBwBY4nuN3A2pPQBHCmwCgtbBf 7TBspQbZO3ykjBiovY7Vn1Y= =zn4Z -END PGP SIGNATURE- Accepted: streamripper_1.61.25-2.diff.gz to pool/main/s/streamripper/streamripper_1.61.25-2.diff.gz streamripper_1.61.25-2.dsc to pool/main/s/streamripper/streamripper_1.61.25-2.dsc streamripper_1.61.25-2_i386.deb to pool/main/s/streamripper/streamripper_1.61.25-2_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted gmailfs 0.7.2-2 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Wed, 23 Aug 2006 23:57:29 -0700 Source: gmailfs Binary: gmailfs Architecture: source all Version: 0.7.2-2 Distribution: unstable Urgency: low Maintainer: Sebastien Delafond [EMAIL PROTECTED] Changed-By: Sebastien Delafond [EMAIL PROTECTED] Description: gmailfs- Use your GMail account as a filesystem Closes: 384420 Changes: gmailfs (0.7.2-2) unstable; urgency=low . * Added missing docbook-to-man build dependency (Closes: 384420). Files: 934bc58c4ade5f663c7d23bce77f44d6 696 utils extra gmailfs_0.7.2-2.dsc dc93f584ae58fe34efd1c1fe49a65758 9227 utils extra gmailfs_0.7.2-2.diff.gz bc72641ae5028511fd91db6905ef6d4f 25180 utils extra gmailfs_0.7.2-2_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (GNU/Linux) iD8DBQFE7U3+iZgNKcDdyD8RAttrAJ46WT0p1gGVJobvDnBAkWZEteBq8ACgjjXj ziFaZZQ2FUlPYoFX8BUL2TY= =i0KO -END PGP SIGNATURE- Accepted: gmailfs_0.7.2-2.diff.gz to pool/main/g/gmailfs/gmailfs_0.7.2-2.diff.gz gmailfs_0.7.2-2.dsc to pool/main/g/gmailfs/gmailfs_0.7.2-2.dsc gmailfs_0.7.2-2_all.deb to pool/main/g/gmailfs/gmailfs_0.7.2-2_all.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
[moz-bonobo-list] Accepted mozilla-bonobo 0.4.2.1-3 (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Wed, 23 Aug 2006 23:40:25 +0200 Source: mozilla-bonobo Binary: mozilla-bonobo Architecture: source i386 Version: 0.4.2.1-3 Distribution: unstable Urgency: low Maintainer: Andrew Lau [EMAIL PROTECTED] Changed-By: Loic Minier [EMAIL PROTECTED] Description: mozilla-bonobo - Mozilla plugin support for Bonobo components Closes: 384229 Changes: mozilla-bonobo (0.4.2.1-3) unstable; urgency=low . * Bump up Debhelper compatibility level to 5. * Drop useless debian/dirs. * Bump up Standards-Version to 3.7.2. * Drop gnome-gv from Suggests as it no longer provides a bonobo interface; thanks Christian Hammers. (Closes: #384229) Files: 5c4d1a167fdfc08d52aa046a925e37c7 1434 gnome optional mozilla-bonobo_0.4.2.1-3.dsc e7702f7d1d4522e97cdf06ea5e15935b 276724 gnome optional mozilla-bonobo_0.4.2.1-3.diff.gz 731fdfbf94af77c4de12439c89c2c4ce 30962 gnome optional mozilla-bonobo_0.4.2.1-3_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQFE7WB54VUX8isJIMARAvgXAJwJQ1+7+Md3qTdm0hep/HDw0QNfyQCfXtGp 61jtrnv9FKNInlR16Oz9lTE= =KdYx -END PGP SIGNATURE- Accepted: mozilla-bonobo_0.4.2.1-3.diff.gz to pool/main/m/mozilla-bonobo/mozilla-bonobo_0.4.2.1-3.diff.gz mozilla-bonobo_0.4.2.1-3.dsc to pool/main/m/mozilla-bonobo/mozilla-bonobo_0.4.2.1-3.dsc mozilla-bonobo_0.4.2.1-3_i386.deb to pool/main/m/mozilla-bonobo/mozilla-bonobo_0.4.2.1-3_i386.deb ___ moz-bonobo-list mailing list [EMAIL PROTECTED] http://lists.nongnu.org/mailman/listinfo/moz-bonobo-list
Accepted bakery2.4 2.4.0-2 (source all i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Thu, 24 Aug 2006 00:39:08 -0700 Source: bakery2.4 Binary: libbakery-common libbakery-2.4-dev libbakery-2.4-1 Architecture: source all i386 Version: 2.4.0-2 Distribution: unstable Urgency: low Maintainer: Bradley Bell [EMAIL PROTECTED] Changed-By: Bradley Bell [EMAIL PROTECTED] Description: libbakery-2.4-1 - A C++ Application Framework (shared libraries) libbakery-2.4-dev - A C++ Application Framework (development files) libbakery-common - A C++ Application Framework (common files) Closes: 384421 Changes: bakery2.4 (2.4.0-2) unstable; urgency=low . * Build-dep on doxygen (Closes: #384421) Files: 5dfb5f8684b64c3cd4f692afe4e7af89 797 libs optional bakery2.4_2.4.0-2.dsc 52d0c360906bbd85f0b4fb3d618788d7 9418 libs optional bakery2.4_2.4.0-2.diff.gz 4a2178cb79a9b12bd0c03273cef5cc47 885462 libdevel optional libbakery-2.4-dev_2.4.0-2_i386.deb 3e246abc08a822f18acb2267d7bedcbc 110808 libs optional libbakery-2.4-1_2.4.0-2_i386.deb 4f8be4c1ca5a276ea8020230326b091f 24168 libs optional libbakery-common_2.4.0-2_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQFE7Vw+teAcXeZ40aERAgxrAKCM9f5H7LsBt4c02NsBZedpnRQJlwCeJW0M aKKg3mHaqBkvEXqiRYzakhE= =m+hr -END PGP SIGNATURE- Accepted: bakery2.4_2.4.0-2.diff.gz to pool/main/b/bakery2.4/bakery2.4_2.4.0-2.diff.gz bakery2.4_2.4.0-2.dsc to pool/main/b/bakery2.4/bakery2.4_2.4.0-2.dsc libbakery-2.4-1_2.4.0-2_i386.deb to pool/main/b/bakery2.4/libbakery-2.4-1_2.4.0-2_i386.deb libbakery-2.4-dev_2.4.0-2_i386.deb to pool/main/b/bakery2.4/libbakery-2.4-dev_2.4.0-2_i386.deb libbakery-common_2.4.0-2_all.deb to pool/main/b/bakery2.4/libbakery-common_2.4.0-2_all.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted istanbul 0.2.1-1 (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Wed, 16 Aug 2006 09:41:13 +0200 Source: istanbul Binary: istanbul Architecture: source i386 Version: 0.2.1-1 Distribution: unstable Urgency: low Maintainer: Luca Bruno [EMAIL PROTECTED] Changed-By: Luca Bruno [EMAIL PROTECTED] Description: istanbul - Desktop session recorder Closes: 382416 Changes: istanbul (0.2.1-1) unstable; urgency=low . * New upstream release (codename: Freedom to record speech) * istanbul can now record audio, added dependecies on gstreamer-alsa plugins * Patch from CVS to workaround a bug in a Xv driver (Closes: #382416) * Improved handling of gconf schemas and added related dependecies Files: 135f668a9da594b85f24a40f18ca227c 920 gnome optional istanbul_0.2.1-1.dsc 7173fc595fcb74ca532f34c81e4daf1b 449619 gnome optional istanbul_0.2.1.orig.tar.gz d919199a6b1a0c8cc093359dbc2cd12c 4949 gnome optional istanbul_0.2.1-1.diff.gz 50d9f1a1b90dd9df3e8f27bf94f64d3f 47246 gnome optional istanbul_0.2.1-1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQFE7WBw4VUX8isJIMARAvs/AKCTjASmJsrBe0CQieKHZRm+AWBPJwCcDQwA rghsPsQtVRQOez/NzQIZdBw= =GKXY -END PGP SIGNATURE- Accepted: istanbul_0.2.1-1.diff.gz to pool/main/i/istanbul/istanbul_0.2.1-1.diff.gz istanbul_0.2.1-1.dsc to pool/main/i/istanbul/istanbul_0.2.1-1.dsc istanbul_0.2.1-1_i386.deb to pool/main/i/istanbul/istanbul_0.2.1-1_i386.deb istanbul_0.2.1.orig.tar.gz to pool/main/i/istanbul/istanbul_0.2.1.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted ifupdown 0.6.7-0.1 (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Wed, 23 Aug 2006 17:01:03 +0200 Source: ifupdown Binary: ifupdown Architecture: source i386 Version: 0.6.7-0.1 Distribution: unstable Urgency: low Maintainer: Anthony Towns [EMAIL PROTECTED] Changed-By: Mohammed Adnène Trojette [EMAIL PROTECTED] Description: ifupdown - high level tools to configure network interfaces Closes: 266021 312988 Changes: ifupdown (0.6.7-0.1) unstable; urgency=low . * Non-maintainer upload with authorization from maintainer. * Support for link-local IPv6 gateways (Closes: #312988) - patch from Florian Zumbiehl. * Support for manual IPv6 method (Closes: #266021) - patch from Rémi Denis-Courmont. Files: 58eade642a0367ae8054a31441fe 510 base important ifupdown_0.6.7-0.1.dsc 63de5641f9cb1dbfa286cba8854f655a 346630 base important ifupdown_0.6.7-0.1.tar.gz 1e650102e195e57cf79bd40978a4568a 48944 base important ifupdown_0.6.7-0.1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQFE7WPhvPbGD26BadIRArbrAKCFUsnKyZeH7vJmUWkbHcPs20EeLwCbBlfR 8/aVkk8pR0D/2rMrwjgTNkg= =0Wnl -END PGP SIGNATURE- Accepted: ifupdown_0.6.7-0.1.dsc to pool/main/i/ifupdown/ifupdown_0.6.7-0.1.dsc ifupdown_0.6.7-0.1.tar.gz to pool/main/i/ifupdown/ifupdown_0.6.7-0.1.tar.gz ifupdown_0.6.7-0.1_i386.deb to pool/main/i/ifupdown/ifupdown_0.6.7-0.1_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted upgrade-system 1.0.1.3 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Thu, 24 Aug 2006 10:09:10 +0300 Source: upgrade-system Binary: upgrade-system Architecture: source all Version: 1.0.1.3 Distribution: unstable Urgency: low Maintainer: Martin-Ãric Racine [EMAIL PROTECTED] Changed-By: Martin-Ãric Racine [EMAIL PROTECTED] Description: upgrade-system - system upgrader from Konflux Changes: upgrade-system (1.0.1.3) unstable; urgency=low . * Added Linda and Lintian overrides for build-depends-without-arch-dep on arch:all package (reason: needed by 'clean' target). Files: 9675769e8633324902880b6a079a8bd6 546 admin optional upgrade-system_1.0.1.3.dsc 9018ffd4b07e46a5cef79fbc61388ca8 8010 admin optional upgrade-system_1.0.1.3.tar.gz 543b191775ab1745270cc48d90c667e8 10088 admin optional upgrade-system_1.0.1.3_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (GNU/Linux) iEYEARECAAYFAkTtaW4ACgkQQKW+7XLQPLGQtQCgt09VHpfqRPJ616N8h/bxDNSX kP0AnjgcZZQ+Qo7nXtx8HarEKdF8UgS5 =jfDj -END PGP SIGNATURE- Accepted: upgrade-system_1.0.1.3.dsc to pool/main/u/upgrade-system/upgrade-system_1.0.1.3.dsc upgrade-system_1.0.1.3.tar.gz to pool/main/u/upgrade-system/upgrade-system_1.0.1.3.tar.gz upgrade-system_1.0.1.3_all.deb to pool/main/u/upgrade-system/upgrade-system_1.0.1.3_all.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted planner 0.14-10 (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Thu, 24 Aug 2006 09:01:24 +0300 Source: planner Binary: planner planner-dev Architecture: source i386 Version: 0.14-10 Distribution: unstable Urgency: high Maintainer: Martin-Ãric Racine [EMAIL PROTECTED] Changed-By: Martin-Ãric Racine [EMAIL PROTECTED] Description: planner- project management application planner-dev - Planner development library Closes: 384364 Changes: planner (0.14-10) unstable; urgency=high . * Anticipate for ANY Python version in install (Closes: #384364). Files: 2e0be63d4ae4722f21d102ec7c34bd45 894 gnome optional planner_0.14-10.dsc 8d1fe16e86fa8f3d6e1a93c9e57c861b 46405 gnome optional planner_0.14-10.diff.gz e7c400e54a3ee490c637c65ed44962d6 3545710 gnome optional planner_0.14-10_i386.deb c2443baee12772006e43b13e2885daf3 42378 libdevel optional planner-dev_0.14-10_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (GNU/Linux) iEYEARECAAYFAkTtaMgACgkQQKW+7XLQPLFbzACeMnuUYlGXMoLPAP/sjyaxKnYI slwAoLQdLE10dfU37LR//NVtcQ3QiPh+ =+Xx6 -END PGP SIGNATURE- Accepted: planner-dev_0.14-10_i386.deb to pool/main/p/planner/planner-dev_0.14-10_i386.deb planner_0.14-10.diff.gz to pool/main/p/planner/planner_0.14-10.diff.gz planner_0.14-10.dsc to pool/main/p/planner/planner_0.14-10.dsc planner_0.14-10_i386.deb to pool/main/p/planner/planner_0.14-10_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted gcc-snapshot 20060823-1 (source i386 amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Wed, 23 Aug 2006 21:00:42 +0200 Source: gcc-snapshot Binary: gcc-snapshot Architecture: amd64 i386 source Version: 20060823-1 Distribution: unstable Urgency: low Maintainer: Debian GCC Maintainers debian-gcc@lists.debian.org Changed-By: Martin Michlmayr [EMAIL PROTECTED] Description: gcc-snapshot - A SNAPSHOT of the GNU Compiler Collection Closes: 369938 370594 376616 379767 379866 Changes: gcc-snapshot (20060823-1) unstable; urgency=low . * SVN 20060823, taken from the trunk, revision 116355. - PR tree-optimization/27882: segfault in ipa-inline.c (closes: #369938). - PR c++/28479: g++ goes into infinite loop compiling zhcon (closes: #379767). - PR c/28280: bogus statement with no effect warning with VLA and typeof (closes: #376616). - PR rtl-optimization/27907 (alpha): ICE in expand_simple_unop, at optabs.c:2307 (closes: #370594). - PR rtl-optimization/28489 (ia64): ICE in move_insn, at haifa-sched.c:1968 (closes: #379866). - PR target/26655 (ia64): ICE in reload_cse_simplify_operands, at postreload.c:393 for invalid assembler (see #380121). Files: 0c7be391f884929e5188832e3bc6af37 2448 devel standard gcc-snapshot_20060823-1.dsc 62ccb40aa72d839cf7433e96d1c46b34 103691316 devel extra gcc-snapshot_20060823-1_i386.deb 80c3715808db53236cd7bf11f0807be9 39428359 devel standard gcc-snapshot_20060823-1.tar.gz 8324542cfee23391b9cb5e50d64385bb 105886134 devel extra gcc-snapshot_20060823-1_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (GNU/Linux) iD8DBQFE7W/fKb5dImj9VJ8RAk1wAJ4mpcUJAm+GEXl2mUiSgm73UV+1XwCgppw+ 4rwRRMvzZpQMGEPx6Qd1/24= =LGo+ -END PGP SIGNATURE- Accepted: gcc-snapshot_20060823-1.dsc to pool/main/g/gcc-snapshot/gcc-snapshot_20060823-1.dsc gcc-snapshot_20060823-1.tar.gz to pool/main/g/gcc-snapshot/gcc-snapshot_20060823-1.tar.gz gcc-snapshot_20060823-1_amd64.deb to pool/main/g/gcc-snapshot/gcc-snapshot_20060823-1_amd64.deb gcc-snapshot_20060823-1_i386.deb to pool/main/g/gcc-snapshot/gcc-snapshot_20060823-1_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted centericq 4.21.0-14 (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Thu, 24 Aug 2006 11:01:29 +0200 Source: centericq Binary: centericq-common centericq-utf8 centericq-fribidi centericq Architecture: source i386 Version: 4.21.0-14 Distribution: unstable Urgency: low Maintainer: Julien Lemoine [EMAIL PROTECTED] Changed-By: Julien Lemoine [EMAIL PROTECTED] Description: centericq - A text-mode multi-protocol instant messenger client centericq-common - A text-mode multi-protocol instant messenger client (data files) centericq-fribidi - A text-mode multi-protocol instant messenger client (Hebrew) centericq-utf8 - A text-mode multi-protocol instant messenger client Changes: centericq (4.21.0-14) unstable; urgency=low . * Added build depend on automake1.4 to fix build failure Files: 0f3001d9303fedc3e196044da17011bd 852 net optional centericq_4.21.0-14.dsc d587cec833e5d4cbcb535832f63e8aac 178909 net optional centericq_4.21.0-14.diff.gz e40eec6b8074aef6bc98442f923c2a58 346018 net optional centericq-common_4.21.0-14_i386.deb 997dd4fd8e9317273aa54aad369e69bd 1273316 net optional centericq_4.21.0-14_i386.deb 09d17783674ef8862ec7149e3248c606 1273332 net optional centericq-utf8_4.21.0-14_i386.deb 76481f5f86394d4e735523fdab341ca3 1273846 net optional centericq-fribidi_4.21.0-14_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQFE7XEmc29c8N2YKnURAklSAKCFxjcDcooPh1XLphLTO97ZFAmIfACfauRs 1NtN2llzrRWw/N0yl7vz8MU= =iZXC -END PGP SIGNATURE- Accepted: centericq-common_4.21.0-14_i386.deb to pool/main/c/centericq/centericq-common_4.21.0-14_i386.deb centericq-fribidi_4.21.0-14_i386.deb to pool/main/c/centericq/centericq-fribidi_4.21.0-14_i386.deb centericq-utf8_4.21.0-14_i386.deb to pool/main/c/centericq/centericq-utf8_4.21.0-14_i386.deb centericq_4.21.0-14.diff.gz to pool/main/c/centericq/centericq_4.21.0-14.diff.gz centericq_4.21.0-14.dsc to pool/main/c/centericq/centericq_4.21.0-14.dsc centericq_4.21.0-14_i386.deb to pool/main/c/centericq/centericq_4.21.0-14_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted puredata 0.40.0~test04-1 (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Thu, 24 Aug 2006 11:53:48 +0200 Source: puredata Binary: puredata Architecture: source i386 Version: 0.40.0~test04-1 Distribution: experimental Urgency: low Maintainer: Guenter Geiger (Debian/GNU) [EMAIL PROTECTED] Changed-By: Guenter Geiger (Debian/GNU) [EMAIL PROTECTED] Description: puredata - realtime computer music and graphics system Changes: puredata (0.40.0~test04-1) experimental; urgency=low . * New upstream version * removed empty 64_bit_arrays patch * removed fix_s_stuff_include.patch * build depends conditionally on libasound2-dev Files: fc17a8be773c820b73163aee86ed5ee1 717 sound optional puredata_0.40.0~test04-1.dsc d7194e780c8e139c9ac9e586a5df49a4 2170929 sound optional puredata_0.40.0~test04.orig.tar.gz 7e4636bcc0ffef32e4fcc4ad14040940 10093 sound optional puredata_0.40.0~test04-1.diff.gz 853c9f3459a09d788301a0eba1133d4c 1541198 sound optional puredata_0.40.0~test04-1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (GNU/Linux) iD8DBQFE7XhC1pbKhmC2uVgRAlSHAJ97IkIN0Yer6ZBbfFqYprIhwTBa9gCfeI+V wJoFX6QCS70AzTtK+Z6p1eY= =Zc1/ -END PGP SIGNATURE- Accepted: puredata_0.40.0~test04-1.diff.gz to pool/main/p/puredata/puredata_0.40.0~test04-1.diff.gz puredata_0.40.0~test04-1.dsc to pool/main/p/puredata/puredata_0.40.0~test04-1.dsc puredata_0.40.0~test04-1_i386.deb to pool/main/p/puredata/puredata_0.40.0~test04-1_i386.deb puredata_0.40.0~test04.orig.tar.gz to pool/main/p/puredata/puredata_0.40.0~test04.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted puredata 0.39.2-4 (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Thu, 24 Aug 2006 11:46:16 +0200 Source: puredata Binary: puredata Architecture: source i386 Version: 0.39.2-4 Distribution: unstable Urgency: low Maintainer: Guenter Geiger (Debian/GNU) [EMAIL PROTECTED] Changed-By: Guenter Geiger (Debian/GNU) [EMAIL PROTECTED] Description: puredata - realtime computer music and graphics system Changes: puredata (0.39.2-4) unstable; urgency=low . * Added platform depended build dependencies to libasound2-dev Files: 38ee3d4a4db03c01ea178c2f36583d6a 696 sound optional puredata_0.39.2-4.dsc 34fa8fccfc129cf0ff4bc0380229fab1 10212 sound optional puredata_0.39.2-4.diff.gz a8127786b17553df33e0205f2462cc2a 1531270 sound optional puredata_0.39.2-4_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (GNU/Linux) iD8DBQFE7XX31pbKhmC2uVgRAuHOAJ49LTv5sv8yAnMJ78LiOv6LTG73BQCdGELf e7nnenOcaCRHuQiaThsGxds= =lw9X -END PGP SIGNATURE- Accepted: puredata_0.39.2-4.diff.gz to pool/main/p/puredata/puredata_0.39.2-4.diff.gz puredata_0.39.2-4.dsc to pool/main/p/puredata/puredata_0.39.2-4.dsc puredata_0.39.2-4_i386.deb to pool/main/p/puredata/puredata_0.39.2-4_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted fkiss 0.34-4 (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Fri, 18 Aug 2006 08:52:50 +0200 Source: fkiss Binary: fkiss Architecture: source i386 Version: 0.34-4 Distribution: unstable Urgency: low Maintainer: Amaya Rodrigo Sastre [EMAIL PROTECTED] Changed-By: Amaya Rodrigo Sastre [EMAIL PROTECTED] Description: fkiss - Implementation of KISekae Set System (KISS) for the X Window Syst Changes: fkiss (0.34-4) unstable; urgency=low . * Rebuild to fix: fkiss: Depends: libc6 (= 2.4-1) Files: a690eb7469c9fa6bf8d92f890ea1c512 573 games optional fkiss_0.34-4.dsc 3992647867b0436fc690e07d94b23f34 114718 games optional fkiss_0.34-4.diff.gz 24a40e754cbbc366961fa1841ac91474 101342 games optional fkiss_0.34-4_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQFE7YQsNFDtUT/MKpARAklMAJ0Yk7QqdlCywQwZDinzp++fCwRF7QCgpvur Phyx2z43dShEjTQ+pNl3Kl8= =t6MG -END PGP SIGNATURE- Accepted: fkiss_0.34-4.diff.gz to pool/main/f/fkiss/fkiss_0.34-4.diff.gz fkiss_0.34-4.dsc to pool/main/f/fkiss/fkiss_0.34-4.dsc fkiss_0.34-4_i386.deb to pool/main/f/fkiss/fkiss_0.34-4_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted tex-common 0.28 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Wed, 23 Aug 2006 22:09:37 +0200 Source: tex-common Binary: tex-common Architecture: source all Version: 0.28 Distribution: unstable Urgency: low Maintainer: Debian TeX maintainers [EMAIL PROTECTED] Changed-By: Frank Küster [EMAIL PROTECTED] Description: tex-common - Common infrastructure for using and building TeX in Debian Closes: 384333 Changes: tex-common (0.28) unstable; urgency=low . * Fix spelling of medium in the last upload * Remove jadetex settings from texmf.d (closes: #384333) [frank] * Add a paragraph to the Policy how to handle format creation when latex.fmt or other basic formats are needed [frank] Files: f88440cfff8477995e9b16642ffe56d4 756 tex optional tex-common_0.28.dsc 28311547895cc442b1c4b9a5a197cfa7 303580 tex optional tex-common_0.28.tar.gz 0882142a6a3334f5d35f125699048ed7 291154 tex optional tex-common_0.28_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQFE7YiR+xs9YyJS+hoRAveVAJ42vlJmUlq2pK0dhfkJq+3WFW4+rQCfTloL J+AWTDfXIEZ8e0iMH0JaEIE= =kBrm -END PGP SIGNATURE- Accepted: tex-common_0.28.dsc to pool/main/t/tex-common/tex-common_0.28.dsc tex-common_0.28.tar.gz to pool/main/t/tex-common/tex-common_0.28.tar.gz tex-common_0.28_all.deb to pool/main/t/tex-common/tex-common_0.28_all.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted dmenu 0.5-1 (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Thu, 24 Aug 2006 14:12:00 +0200 Source: dmenu Binary: dmenu Architecture: source i386 Version: 0.5-1 Distribution: unstable Urgency: low Maintainer: Daniel Baumann [EMAIL PROTECTED] Changed-By: Daniel Baumann [EMAIL PROTECTED] Description: dmenu - dynamic menu Changes: dmenu (0.5-1) unstable; urgency=low . * New upstream release. Files: 991557356fb01eca3127357f3783499b 554 x11 optional dmenu_0.5-1.dsc fcfc83cbdc9a9febef42e5d6be37568c 7034 x11 optional dmenu_0.5.orig.tar.gz 60cc5ccf434ffc4cc2a88b8ca569215d 1792 x11 optional dmenu_0.5-1.diff.gz 87689db092d89d26093300e36af77dde 8648 x11 optional dmenu_0.5-1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQFE7Zer+C5cwEsrK54RAkOqAJ4+TFXLfJI44Kn3wMj3H7fhcjmgPACeNFla LBUcJV8/eb2wQDAZ9KYn/Ic= =cHvx -END PGP SIGNATURE- Accepted: dmenu_0.5-1.diff.gz to pool/main/d/dmenu/dmenu_0.5-1.diff.gz dmenu_0.5-1.dsc to pool/main/d/dmenu/dmenu_0.5-1.dsc dmenu_0.5-1_i386.deb to pool/main/d/dmenu/dmenu_0.5-1_i386.deb dmenu_0.5.orig.tar.gz to pool/main/d/dmenu/dmenu_0.5.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted dwm 1.0-1 (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Tue, 24 Aug 2006 14:10:00 +0200 Source: dwm Binary: dwm Architecture: source i386 Version: 1.0-1 Distribution: unstable Urgency: low Maintainer: Daniel Baumann [EMAIL PROTECTED] Changed-By: Daniel Baumann [EMAIL PROTECTED] Description: dwm- dynamic window manager Changes: dwm (1.0-1) unstable; urgency=low . * New upstream release. Files: 7553cdb7583c28a387a092052a3586d9 566 x11 optional dwm_1.0-1.dsc 587f56bef064d5c6ce115971fd6ef8c2 15444 x11 optional dwm_1.0.orig.tar.gz 0f65bacaa1ad38b017f05cdf8cfbe1d8 3418 x11 optional dwm_1.0-1.diff.gz 976e2409ff4b435b15f0ffaab5c4786d 17820 x11 optional dwm_1.0-1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQFE7Zda+C5cwEsrK54RAmlHAKCBmHuUHt3PizaEmG1hzSiIhHswSACgggOw 1733aXPM+9G/f0kukWyOQAo= =iz9q -END PGP SIGNATURE- Accepted: dwm_1.0-1.diff.gz to pool/main/d/dwm/dwm_1.0-1.diff.gz dwm_1.0-1.dsc to pool/main/d/dwm/dwm_1.0-1.dsc dwm_1.0-1_i386.deb to pool/main/d/dwm/dwm_1.0-1_i386.deb dwm_1.0.orig.tar.gz to pool/main/d/dwm/dwm_1.0.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted python-uncertainities 0.002-2 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Thu, 24 Aug 2006 09:54:52 +0200 Source: python-uncertainities Binary: python-uncertainities Architecture: source all Version: 0.002-2 Distribution: unstable Urgency: low Maintainer: Debian QA Group [EMAIL PROTECTED] Changed-By: Radovan GarabÃk [EMAIL PROTECTED] Description: python-uncertainities - Python module for working with uncertain numbers Changes: python-uncertainities (0.002-2) unstable; urgency=low . * NMU: moved dh_installdeb after dh_pycentral, so that postinst and prerm are created. Package was unusable without this. Files: 9c9def5ffa89e5d428f4ef201928c7da 689 python optional python-uncertainities_0.002-2.dsc 6d44ec55ec9322a225da6afb0c142945 1964 python optional python-uncertainities_0.002-2.diff.gz a7a2c685d0d1d3aa255b7707ab7a92a9 3726 python optional python-uncertainities_0.002-2_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (GNU/Linux) iD8DBQFE7aOqUBQJxqD+WLgRAmydAJ9vMcjpmtf+3INdBlGA4/b+PvMs7gCfcaN8 8omKH+DI62khdcUSktxQfN0= =p2Wm -END PGP SIGNATURE- Accepted: python-uncertainities_0.002-2.diff.gz to pool/main/p/python-uncertainities/python-uncertainities_0.002-2.diff.gz python-uncertainities_0.002-2.dsc to pool/main/p/python-uncertainities/python-uncertainities_0.002-2.dsc python-uncertainities_0.002-2_all.deb to pool/main/p/python-uncertainities/python-uncertainities_0.002-2_all.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted kscope 1.4.1-1 (source amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Thu, 24 Aug 2006 12:24:23 +0200 Source: kscope Binary: kscope Architecture: source amd64 Version: 1.4.1-1 Distribution: unstable Urgency: low Maintainer: Debian KDE Extras Team [EMAIL PROTECTED] Changed-By: Fathi Boudra [EMAIL PROTECTED] Description: kscope - source editing environment for KDE Changes: kscope (1.4.1-1) unstable; urgency=low . * New upstream release * Remove 11_crashfix.diff, merged upstream Files: f696a9be710a35124c5d91e2ba9bb1c9 701 kde optional kscope_1.4.1-1.dsc 994e1156026dfa7b02a7ddf83248f108 1252465 kde optional kscope_1.4.1.orig.tar.gz 81eda7cb39854475b32c2ff25f08858e 11129 kde optional kscope_1.4.1-1.diff.gz b0db6b8662acd5b63acd6d80410f5aca 820302 kde optional kscope_1.4.1-1_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQFE7aKtvGr7W6HudhwRAjUGAJ0a3kEwJqxVYHvurhHUX914pVYbZgCfepi0 SFYKcgdJshyXNqUS/RiC4DE= =nJFE -END PGP SIGNATURE- Accepted: kscope_1.4.1-1.diff.gz to pool/main/k/kscope/kscope_1.4.1-1.diff.gz kscope_1.4.1-1.dsc to pool/main/k/kscope/kscope_1.4.1-1.dsc kscope_1.4.1-1_amd64.deb to pool/main/k/kscope/kscope_1.4.1-1_amd64.deb kscope_1.4.1.orig.tar.gz to pool/main/k/kscope/kscope_1.4.1.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted unionfs 1.3+debian-4 (source all i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Thu, 24 Au 2006 15:41:00 +0200 Source: unionfs Binary: unionfs-tools unionfs-source unionfs-utils Architecture: source all i386 Version: 1.3+debian-4 Distribution: unstable Urgency: low Maintainer: Daniel Baumann [EMAIL PROTECTED] Changed-By: Daniel Baumann [EMAIL PROTECTED] Description: unionfs-source - Source for the union filesystem unionfs-tools - Tools to manage unionfs filesystems unionfs-utils - Transition package for unionfs-tools rename Closes: 384451 Changes: unionfs (1.3+debian-4) unstable; urgency=low . * Removed binary modules packages, superseeded with linux-modules-extra-2.6 (Closes: #384451). * Since unionfs-{source,tools} will be moved to l-m-e-2.6 too, this package can be removed soon, this is just an 'intermediate' upload. Files: d102ea7afcb914078d51238800e242de 627 misc optional unionfs_1.3+debian-4.dsc 1a61fcc63e7f23d50360db3e0b033622 5460 misc optional unionfs_1.3+debian-4.diff.gz 6b1218c92c1f208971f3e74754cc6c7f 95538 misc optional unionfs-source_1.3+debian-4_all.deb 8590b4e3d663f35d960e5e161124e6d1 40420 misc optional unionfs-utils_1.3+debian-4_all.deb bb525cb3227ad5b8b24f1f73a0779ab6 69192 misc optional unionfs-tools_1.3+debian-4_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQFE7a8h+C5cwEsrK54RAr3hAKDHDcbM4ktwZkUD6fCuBPuaeUIWbwCeN4vu HXuA58vxRJWy09m2mlLbAo0= =6O4M -END PGP SIGNATURE- Accepted: unionfs-source_1.3+debian-4_all.deb to pool/main/u/unionfs/unionfs-source_1.3+debian-4_all.deb unionfs-tools_1.3+debian-4_i386.deb to pool/main/u/unionfs/unionfs-tools_1.3+debian-4_i386.deb unionfs-utils_1.3+debian-4_all.deb to pool/main/u/unionfs/unionfs-utils_1.3+debian-4_all.deb unionfs_1.3+debian-4.diff.gz to pool/main/u/unionfs/unionfs_1.3+debian-4.diff.gz unionfs_1.3+debian-4.dsc to pool/main/u/unionfs/unionfs_1.3+debian-4.dsc -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted wl-beta 2.15.3+0.20060823-1 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Thu, 24 Aug 2006 23:20:22 +0900 Source: wl-beta Binary: wl-beta Architecture: source all Version: 2.15.3+0.20060823-1 Distribution: unstable Urgency: low Maintainer: Tatsuya Kinoshita [EMAIL PROTECTED] Changed-By: Tatsuya Kinoshita [EMAIL PROTECTED] Description: wl-beta- mail/news reader supporting IMAP for emacsen (development version Changes: wl-beta (2.15.3+0.20060823-1) unstable; urgency=low . * New upstream release. (CVS trunk on 2006-08-23) * debian/control (Description): Use `Homepage:'. * debian/copyright: Change URL of mirror site. * debian/watch: Use mirror site. Files: 0d8e2ce0854ee1825cbed9f899b8b227 644 mail extra wl-beta_2.15.3+0.20060823-1.dsc b0dee7e996ddbd80b996ab732c931846 1107986 mail extra wl-beta_2.15.3+0.20060823.orig.tar.gz 7e92ad041581bdbdaa978fc0b246828b 23096 mail extra wl-beta_2.15.3+0.20060823-1.diff.gz 919263d2c38f951e6ee0f30c1ef2d9f3 941524 mail extra wl-beta_2.15.3+0.20060823-1_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQFE7bW+gV4LPvpMUpgRAtUxAJ9pm/7Ag/ju/VtjgfDcD8EzrxwyVwCfa5U2 v/pLsQJpILEYCqH7D1KmiX4= =orpV -END PGP SIGNATURE- Accepted: wl-beta_2.15.3+0.20060823-1.diff.gz to pool/main/w/wl-beta/wl-beta_2.15.3+0.20060823-1.diff.gz wl-beta_2.15.3+0.20060823-1.dsc to pool/main/w/wl-beta/wl-beta_2.15.3+0.20060823-1.dsc wl-beta_2.15.3+0.20060823-1_all.deb to pool/main/w/wl-beta/wl-beta_2.15.3+0.20060823-1_all.deb wl-beta_2.15.3+0.20060823.orig.tar.gz to pool/main/w/wl-beta/wl-beta_2.15.3+0.20060823.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted emacs-snapshot 1:20060824-1 (source i386 all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Wed, 23 Aug 2006 22:02:14 +0200 Source: emacs-snapshot Binary: emacs-snapshot-el emacs-snapshot-bin-common emacs-snapshot-nox emacs-snapshot emacs-snapshot-common emacs-snapshot-gtk Architecture: source i386 all Version: 1:20060824-1 Distribution: unstable Urgency: low Maintainer: Romain Francoise [EMAIL PROTECTED] Changed-By: Romain Francoise [EMAIL PROTECTED] Description: emacs-snapshot - The GNU Emacs editor (development snapshot) emacs-snapshot-bin-common - The GNU Emacs editor's shared, architecture dependent files emacs-snapshot-common - The GNU Emacs editor's common infrastructure emacs-snapshot-el - GNU Emacs LISP (.el) files emacs-snapshot-gtk - The GNU Emacs editor (with GTK+ 2.x support) emacs-snapshot-nox - The GNU Emacs editor (without X support) Closes: 383814 Changes: emacs-snapshot (1:20060824-1) unstable; urgency=low . * The Sweetness follows release. . * New snapshot. . * debian/control.in: Drop Build-Depends on mailx (closes: #383814). * debian/control: Regenerate. Files: b085df61898e7455d3d77675221f07d3 963 editors optional emacs-snapshot_20060824-1.dsc 2a119ca3a809b93c77bbdc0a37e0dc23 24450082 editors optional emacs-snapshot_20060824.orig.tar.gz 960e6c6c5dce40d7afcc0467a169f046 31545 editors optional emacs-snapshot_20060824-1.diff.gz 9df218b1e55b35e7ec158e3d8c12d48c 18555766 editors optional emacs-snapshot-common_20060824-1_all.deb 81aa051102ef73cc650ecc02eae0fdec 11034520 editors optional emacs-snapshot-el_20060824-1_all.deb 26f8ed119a161630aa5d8deca1f6a9c7 163636 editors optional emacs-snapshot-bin-common_20060824-1_i386.deb 9460482e632e110f9eb59b720d0e8aec 2010280 editors optional emacs-snapshot_20060824-1_i386.deb 8e30e95048bfa3e5f42c03af83094f4b 2002020 editors optional emacs-snapshot-gtk_20060824-1_i386.deb 2dbe67920caa6bb1cb936fd75b0106e7 1749740 editors optional emacs-snapshot-nox_20060824-1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQFE7bOyogN2vsA8Vt8RAvwfAKC/6AxaCZNFGW+Ipc9aHFrjkhsV7wCg2bqF pidG3HZcSSZdYxvVlPUSvFQ= =JGKk -END PGP SIGNATURE- Accepted: emacs-snapshot-bin-common_20060824-1_i386.deb to pool/main/e/emacs-snapshot/emacs-snapshot-bin-common_20060824-1_i386.deb emacs-snapshot-common_20060824-1_all.deb to pool/main/e/emacs-snapshot/emacs-snapshot-common_20060824-1_all.deb emacs-snapshot-el_20060824-1_all.deb to pool/main/e/emacs-snapshot/emacs-snapshot-el_20060824-1_all.deb emacs-snapshot-gtk_20060824-1_i386.deb to pool/main/e/emacs-snapshot/emacs-snapshot-gtk_20060824-1_i386.deb emacs-snapshot-nox_20060824-1_i386.deb to pool/main/e/emacs-snapshot/emacs-snapshot-nox_20060824-1_i386.deb emacs-snapshot_20060824-1.diff.gz to pool/main/e/emacs-snapshot/emacs-snapshot_20060824-1.diff.gz emacs-snapshot_20060824-1.dsc to pool/main/e/emacs-snapshot/emacs-snapshot_20060824-1.dsc emacs-snapshot_20060824-1_i386.deb to pool/main/e/emacs-snapshot/emacs-snapshot_20060824-1_i386.deb emacs-snapshot_20060824.orig.tar.gz to pool/main/e/emacs-snapshot/emacs-snapshot_20060824.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted xserver-xorg-input-keyboard 1:1.1.0-1 (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Fri, 25 Aug 2006 00:47:52 +1000 Source: xserver-xorg-input-keyboard Binary: xserver-xorg-input-kbd Architecture: source i386 Version: 1:1.1.0-1 Distribution: experimental Urgency: low Maintainer: Debian X Strike Force debian-x@lists.debian.org Changed-By: Drew Parsons [EMAIL PROTECTED] Description: xserver-xorg-input-kbd - X.Org X server -- keyboard input driver Changes: xserver-xorg-input-keyboard (1:1.1.0-1) experimental; urgency=low . [ Andres Salomon ] * Test for obj-$(DEB_BUILD_GNU_TYPE) before creating it during build; idempotency fix. * Run dh_install w/ --list-missing. . [ Drew Parsons ] * New upstream version xf86-input-keyboard-1.1.0. * Standards version 3.7.2. * Use debhelper 5. Install manpage using dh_installman. * Exclude .la files from dh_install. Files: 28b33a4f012d5aebd171523c4b634d14 922 x11 optional xserver-xorg-input-keyboard_1.1.0-1.dsc d16d7c684e87543a75b26cfbbe2de565 321415 x11 optional xserver-xorg-input-keyboard_1.1.0.orig.tar.gz 8e695bb52a0cc3431ec44d3367d44bdd 17523 x11 optional xserver-xorg-input-keyboard_1.1.0-1.diff.gz d8d82a715d525ada33d6872cbd67f66a 12744 x11 optional xserver-xorg-input-kbd_1.1.0-1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQFE7b3Bts5wQWQSTkoRAjGeAJ4hie3FsqXgSEXTETHu9rBnXtPrDwCeI3l1 3DRrqoz1vogM7Vpc0ygeIPs= =Kagg -END PGP SIGNATURE- Accepted: xserver-xorg-input-kbd_1.1.0-1_i386.deb to pool/main/x/xserver-xorg-input-keyboard/xserver-xorg-input-kbd_1.1.0-1_i386.deb xserver-xorg-input-keyboard_1.1.0-1.diff.gz to pool/main/x/xserver-xorg-input-keyboard/xserver-xorg-input-keyboard_1.1.0-1.diff.gz xserver-xorg-input-keyboard_1.1.0-1.dsc to pool/main/x/xserver-xorg-input-keyboard/xserver-xorg-input-keyboard_1.1.0-1.dsc xserver-xorg-input-keyboard_1.1.0.orig.tar.gz to pool/main/x/xserver-xorg-input-keyboard/xserver-xorg-input-keyboard_1.1.0.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted udev 0.098-1 (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Thu, 24 Aug 2006 17:21:16 +0200 Source: udev Binary: libvolume-id-dev udev libvolume-id0 udev-udeb Architecture: source i386 Version: 0.098-1 Distribution: experimental Urgency: low Maintainer: Marco d'Itri [EMAIL PROTECTED] Changed-By: Marco d'Itri [EMAIL PROTECTED] Description: libvolume-id-dev - libvolume_id development headers libvolume-id0 - libvolume_id shared library udev - /dev/ and hotplug management daemon udev-udeb - /dev/ and hotplug management daemon (udeb) Closes: 384023 Changes: udev (0.098-1) experimental; urgency=low . * New upstream release. * Converted the rules files to the new syntax. * preinst: added code to upgrade the persistent-{net,cd} rules files. * preinst: removed the code managing upgrades from versions uploaded to unstable before sarge was released. * Removed the udevsettle_timeout patch, since apparently it is not useful. * persistent.rules: do not run {path,scsi,ata}_id on xen block devices. * Added udevinfo to the udeb. (Closes: #384023) Files: 15b12d2167040261a70eafc874acb7a3 623 admin important udev_0.098-1.dsc a85d945f4db7052c84a429b6cd8ffeca 195994 admin important udev_0.098.orig.tar.gz 1adfaae20a7dac6a577bbfb009d7335d 48585 admin important udev_0.098-1.diff.gz d7270ad9d9e5b435eb051d6b97b54d46 260956 admin important udev_0.098-1_i386.deb 26b599a986bee81742977b9328f40cb7 57896 libs important libvolume-id0_0.098-1_i386.deb a03fd9c95cbb99e4d0d2bfb2cf7c2115 15182 libdevel optional libvolume-id-dev_0.098-1_i386.deb 4f9e00b6582317bd1eddc3a8248353bd 100896 debian-installer important udev-udeb_0.098-1_i386.udeb Package-Type: udeb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQFE7cRYFGfw2OHuP7ERAtAxAKCgLNVSMggAljyKJdwXyAuilbq2GwCeOUIS PMkkfmHUw8xlFTRn+o55lcA= =Aun/ -END PGP SIGNATURE- Accepted: libvolume-id-dev_0.098-1_i386.deb to pool/main/u/udev/libvolume-id-dev_0.098-1_i386.deb libvolume-id0_0.098-1_i386.deb to pool/main/u/udev/libvolume-id0_0.098-1_i386.deb udev-udeb_0.098-1_i386.udeb to pool/main/u/udev/udev-udeb_0.098-1_i386.udeb udev_0.098-1.diff.gz to pool/main/u/udev/udev_0.098-1.diff.gz udev_0.098-1.dsc to pool/main/u/udev/udev_0.098-1.dsc udev_0.098-1_i386.deb to pool/main/u/udev/udev_0.098-1_i386.deb udev_0.098.orig.tar.gz to pool/main/u/udev/udev_0.098.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted reniced 1.5-2 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Wed, 2 Aug 2006 21:00:17 +0200 Source: reniced Binary: reniced Architecture: source all Version: 1.5-2 Distribution: unstable Urgency: low Maintainer: Bart Martens [EMAIL PROTECTED] Changed-By: Bart Martens [EMAIL PROTECTED] Description: reniced- renice running processes based on regular expressions Closes: 381201 Changes: reniced (1.5-2) unstable; urgency=low . * Copied from Ubuntu to Debian. Closes: #381201. * debian/*: Repackaged with dh-make 0.41. * debian/copyright: Updated. * debian/watch: Added. Files: 7d8e9d2ef7da07a8b9375c6b208ccf76 546 utils optional reniced_1.5-2.dsc 0eeefab1f1c03a39f2088bf8faaa8480 2196 utils optional reniced_1.5-2.diff.gz e537affc93cd20f94792bdfbf256c724 11466 utils optional reniced_1.5.orig.tar.gz ea1465819a2e4f0d55db08e01d67dbad 7964 utils optional reniced_1.5-2_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (GNU/Linux) iD8DBQFE5PCXipBneRiAKDwRAniDAJ9SnjGMcPYjLPGw7yGBkTmySwem2gCcDFmT HIDL7CGSbovCOMZiBCYuWAs= =1RCE -END PGP SIGNATURE- Accepted: reniced_1.5-2.diff.gz to pool/main/r/reniced/reniced_1.5-2.diff.gz reniced_1.5-2.dsc to pool/main/r/reniced/reniced_1.5-2.dsc reniced_1.5-2_all.deb to pool/main/r/reniced/reniced_1.5-2_all.deb reniced_1.5.orig.tar.gz to pool/main/r/reniced/reniced_1.5.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted subtitleeditor 0.10-2 (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Thu, 17 Aug 2006 10:57:49 +0200 Source: subtitleeditor Binary: subtitleeditor Architecture: source i386 Version: 0.10-2 Distribution: unstable Urgency: low Maintainer: Amaya Rodrigo Sastre [EMAIL PROTECTED] Changed-By: Amaya Rodrigo Sastre [EMAIL PROTECTED] Description: subtitleeditor - Graphical subtitle editor with sound waves representation Closes: 379548 Changes: subtitleeditor (0.10-2) unstable; urgency=low . * The Upstream is too fast for me Release. * Initial release (Closes: #379548). * Fix Spanish Translation. * Ship a README file with actual info. Files: 4121d134bf3f61599f50c5941d1fcce1 720 gnome optional subtitleeditor_0.10-2.dsc 979e7af5a8f3a35a05ab21fdbe87815c 9 gnome optional subtitleeditor_0.10-2.diff.gz e0276b85a9146397fd07d69ecf9e3ee5 479374 gnome optional subtitleeditor_0.10-2_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQFE7dYCNFDtUT/MKpARAgOCAJ95z7aN1r65Gu9PQ9tPa5NK+zWgwQCg3eqU MojIOyiPrdSySxuD2liRyX0= =A3a3 -END PGP SIGNATURE- Accepted: subtitleeditor_0.10-2.diff.gz to pool/main/s/subtitleeditor/subtitleeditor_0.10-2.diff.gz subtitleeditor_0.10-2.dsc to pool/main/s/subtitleeditor/subtitleeditor_0.10-2.dsc subtitleeditor_0.10-2_i386.deb to pool/main/s/subtitleeditor/subtitleeditor_0.10-2_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted ieee80211 1.1.14-1 (source all i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Thu, 17 Aug 2006 18:16:00 +0200 Source: ieee80211 Binary: ieee80211-headers-2.6 ieee80211-modules-2.6-em64t-p4-smp ieee80211-modules-2.6.17-2-486 ieee80211-headers-2.6.17-2 ieee80211-modules-2.6.17-2-em64t-p4 ieee80211-modules-2.6.17-2-k7 ieee80211-modules-2.6-686 ieee80211-modules-2.6.17-2-686 ieee80211-modules-2.6.17-2-em64t-p4-smp ieee80211-source ieee80211-modules-2.6.17-2-amd64-k8 ieee80211-modules-2.6-k7 ieee80211-modules-2.6-amd64-k8 ieee80211-modules-2.6-em64t-p4 ieee80211-modules-2.6.17-2-amd64-k8-smp ieee80211-modules-2.6-amd64-k8-smp ieee80211-modules-2.6-486 ieee80211-modules-2.6.17-2-686-bigmem ieee80211-modules-2.6-686-bigmem Architecture: source all i386 Version: 1.1.14-1 Distribution: unstable Urgency: low Maintainer: Daniel Baumann [EMAIL PROTECTED] Changed-By: Daniel Baumann [EMAIL PROTECTED] Description: ieee80211-headers-2.6 - 802.11 (wireless) network stack headers for Linux 2.6 ieee80211-headers-2.6.17-2 - 802.11 (wireless) network stack headers for Linux 2.6.17-2 ieee80211-modules-2.6-486 - 802.11 (wireless) network stack module for 486-class machines ieee80211-modules-2.6-686 - 802.11 (wireless) network stack module for PPro/Celeron/PII/PIII/ ieee80211-modules-2.6-686-bigmem - 802.11 (wireless) network stack module for PPro/Celeron/PII/PIII/ ieee80211-modules-2.6-k7 - 802.11 (wireless) network stack module for AMD K7 machines ieee80211-modules-2.6.17-2-486 - 802.11 (wireless) network stack module for Linux 2.6.17-2-486 ieee80211-modules-2.6.17-2-686 - 802.11 (wireless) network stack module for Linux 2.6.17-2-686 ieee80211-modules-2.6.17-2-686-bigmem - 802.11 (wireless) network stack module for Linux 2.6.17-2-686-big ieee80211-modules-2.6.17-2-k7 - 802.11 (wireless) network stack module for Linux 2.6.17-2-k7 ieee80211-source - Source for the 802.11 (wireless) network stack for Linux Closes: 351052 377982 378655 381757 Changes: ieee80211 (1.1.14-1) unstable; urgency=low . * New email address. * New upstream version (Closes: #351052, #378655): - supports current kernel (Closes: #377982). * Redone debian packaging from scratch to build oot-module packages: - using dh_installmodules now (Closes: #381757). Files: d74202daa02a68f78fbd495fa3165159 1209 net optional ieee80211_1.1.14-1.dsc cd380abe9bd25fbf2c205c6b20414e38 67848 net optional ieee80211_1.1.14.orig.tar.gz 76d12110d41c3e9b5fc745654892de0f 6641 net optional ieee80211_1.1.14-1.diff.gz 12f00168fe50084061738b31adf37ecd 22628 net optional ieee80211-headers-2.6.17-2_1.1.14-1_all.deb eac5a140d4a87757e02b9faa3d2b0792 6252 net optional ieee80211-headers-2.6_1.1.14-1_all.deb f267afda778e3d7393e9eb10c55577fe 57850 net optional ieee80211-source_1.1.14-1_all.deb 3e8eafab3a9848f2bc67cf86de5a5f58 457998 net optional ieee80211-modules-2.6.17-2-486_1.1.14-1_i386.deb 1bb937ab9d7db359ddde4d3419983f71 6284 net optional ieee80211-modules-2.6-486_1.1.14-1_i386.deb 661f6254bc713edbf86b7647cb123e65 468236 net optional ieee80211-modules-2.6.17-2-686_1.1.14-1_i386.deb c6032de80e93a073d13e4c55703e1abc 6314 net optional ieee80211-modules-2.6-686_1.1.14-1_i386.deb ec2da5350c55cac659b9f83cec40a1dd 468716 net optional ieee80211-modules-2.6.17-2-686-bigmem_1.1.14-1_i386.deb 37a0b9a5710086b63d065165a68ac6c2 6322 net optional ieee80211-modules-2.6-686-bigmem_1.1.14-1_i386.deb 6f37df2cea5042cad1ed81389f626e6a 472056 net optional ieee80211-modules-2.6.17-2-k7_1.1.14-1_i386.deb 8ed3f6510675e47a3c59cb71c4ea80fc 6296 net optional ieee80211-modules-2.6-k7_1.1.14-1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQFE5bo6+C5cwEsrK54RAjL+AJ4ysmFd0bcZwRkMdIqklYxv96Q90gCffryw pICwDqqTljUfeu6heOIoqmc= =nDe7 -END PGP SIGNATURE- Accepted: ieee80211-headers-2.6.17-2_1.1.14-1_all.deb to pool/main/i/ieee80211/ieee80211-headers-2.6.17-2_1.1.14-1_all.deb ieee80211-headers-2.6_1.1.14-1_all.deb to pool/main/i/ieee80211/ieee80211-headers-2.6_1.1.14-1_all.deb ieee80211-modules-2.6-486_1.1.14-1_i386.deb to pool/main/i/ieee80211/ieee80211-modules-2.6-486_1.1.14-1_i386.deb ieee80211-modules-2.6-686-bigmem_1.1.14-1_i386.deb to pool/main/i/ieee80211/ieee80211-modules-2.6-686-bigmem_1.1.14-1_i386.deb ieee80211-modules-2.6-686_1.1.14-1_i386.deb to pool/main/i/ieee80211/ieee80211-modules-2.6-686_1.1.14-1_i386.deb ieee80211-modules-2.6-k7_1.1.14-1_i386.deb to pool/main/i/ieee80211/ieee80211-modules-2.6-k7_1.1.14-1_i386.deb ieee80211-modules-2.6.17-2-486_1.1.14-1_i386.deb to pool/main/i/ieee80211/ieee80211-modules-2.6.17-2-486_1.1.14-1_i386.deb ieee80211-modules-2.6.17-2-686-bigmem_1.1.14-1_i386.deb to pool/main/i/ieee80211/ieee80211-modules-2.6.17-2-686-bigmem_1.1.14-1_i386.deb ieee80211-modules-2.6.17-2-686_1.1.14-1_i386.deb to pool/main/i/ieee80211/ieee80211-modules-2.6.17-2-686_1.1.14-1_i386.deb ieee80211-modules-2.6.17-2-k7_1.1.14-1_i386.deb to
Accepted libcache-simple-timedexpiry-perl 0.25-1 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Thu, 24 Aug 2006 16:30:43 +0100 Source: libcache-simple-timedexpiry-perl Binary: libcache-simple-timedexpiry-perl Architecture: source all Version: 0.25-1 Distribution: unstable Urgency: low Maintainer: Stephen Quinney [EMAIL PROTECTED] Changed-By: Stephen Quinney [EMAIL PROTECTED] Description: libcache-simple-timedexpiry-perl - Perl module to cache and expire key/value pairs Closes: 329507 Changes: libcache-simple-timedexpiry-perl (0.25-1) unstable; urgency=low . * New upstream release, closes: #329507 * New maintainer Files: 814b82c82e6e52e13f18a95cda7f5314 678 perl optional libcache-simple-timedexpiry-perl_0.25-1.dsc 8693c5ea3c5e76c10a78db73c3685a8f 12962 perl optional libcache-simple-timedexpiry-perl_0.25.orig.tar.gz 131e54d0740b7784359790d76d7d2048 1770 perl optional libcache-simple-timedexpiry-perl_0.25-1.diff.gz e9c7ce2942d21d85586842dc892595a1 5630 perl optional libcache-simple-timedexpiry-perl_0.25-1_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQFE7cmkITGblEwaW+URAjlIAKDF5pwMrxbVr6zWpAqQAdqafr1iBQCfV6eX kbcTy168T89lDEWX9zzv2Mc= =8zYY -END PGP SIGNATURE- Accepted: libcache-simple-timedexpiry-perl_0.25-1.diff.gz to pool/main/libc/libcache-simple-timedexpiry-perl/libcache-simple-timedexpiry-perl_0.25-1.diff.gz libcache-simple-timedexpiry-perl_0.25-1.dsc to pool/main/libc/libcache-simple-timedexpiry-perl/libcache-simple-timedexpiry-perl_0.25-1.dsc libcache-simple-timedexpiry-perl_0.25-1_all.deb to pool/main/libc/libcache-simple-timedexpiry-perl/libcache-simple-timedexpiry-perl_0.25-1_all.deb libcache-simple-timedexpiry-perl_0.25.orig.tar.gz to pool/main/libc/libcache-simple-timedexpiry-perl/libcache-simple-timedexpiry-perl_0.25.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted evolution-sharp 0.11.1-2 (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Thu, 24 Aug 2006 00:53:59 +0200 Source: evolution-sharp Binary: libevolution2.0-cil Architecture: source i386 Version: 0.11.1-2 Distribution: unstable Urgency: low Maintainer: Debian Mono Group [EMAIL PROTECTED] Changed-By: Jose Carlos Garcia Sogo [EMAIL PROTECTED] Description: libevolution2.0-cil - CLI bindings for Evolution Closes: 383184 Changes: evolution-sharp (0.11.1-2) unstable; urgency=low . * Added build dependency in libebook1.2-dev and libecal1.2-dev. ACK previous NMU on this. Thanks Margarita! (Closes: #383184) * Change package name to libevolution2.0-cil, to comply with Debian Mono Policy. Files: f228835f52784e8069e7c150cd632ae7 936 libs optional evolution-sharp_0.11.1-2.dsc e026e8efa2338099940f501d9db79386 3173 libs optional evolution-sharp_0.11.1-2.diff.gz e245b1ef7ea1d9da67dd9bd00ebec1de 98250 libs optional libevolution2.0-cil_0.11.1-2_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQFE7OjQS+BYJZB4jhERArw/AJ9a/kRCl0KIfqJVx5Sf8HLQMkhyUgCfYmj/ mprpewBaJ9rh5VNtSQLziS8= =YL4M -END PGP SIGNATURE- Accepted: evolution-sharp_0.11.1-2.diff.gz to pool/main/e/evolution-sharp/evolution-sharp_0.11.1-2.diff.gz evolution-sharp_0.11.1-2.dsc to pool/main/e/evolution-sharp/evolution-sharp_0.11.1-2.dsc libevolution2.0-cil_0.11.1-2_i386.deb to pool/main/e/evolution-sharp/libevolution2.0-cil_0.11.1-2_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted net-snmp 5.2.3-1 (source all sparc)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Thu, 24 Aug 2006 12:23:29 +0200 Source: net-snmp Binary: libsnmp9 tkmib snmp libsnmp-perl libsnmp-base libsnmp9-dev snmpd Architecture: source all sparc Version: 5.2.3-1 Distribution: unstable Urgency: low Maintainer: Net-SNMP Packaging Team [EMAIL PROTECTED] Changed-By: Jochen Friedrich [EMAIL PROTECTED] Description: libsnmp-base - NET SNMP (Simple Network Management Protocol) MIBs and Docs libsnmp-perl - NET SNMP (Simple Network Management Protocol) Perl5 Support libsnmp9 - NET SNMP (Simple Network Management Protocol) Library libsnmp9-dev - NET SNMP (Simple Network Management Protocol) Development Files snmp - NET SNMP (Simple Network Management Protocol) Apps snmpd - NET SNMP (Simple Network Management Protocol) Agents tkmib - NET SNMP (Simple Network Management Protocol) MIB Browser Closes: 381451 384367 Changes: net-snmp (5.2.3-1) unstable; urgency=low . * New upstream version in 5.2.X branch (bugfix release) o snmpd: - Build fixes, e.g. for latest gcc - Return no access instead of not writable on VACM denials - Prevent endless loop in table_iterator - extend: recognize failed/duplicate registrations - Various robustness fixes for some mib implementations - A few memory leak fixes - Other misc bug fixes. o snmptrapd: - Fixed support for snmptrapd embedded perl on x86_64 - Other misc bug fixes. o library: - Make SNMPv3 traps work again (user creation; official patch 1374087) - Fixes typing issues problem with MIB definitions that use intermediate sub-identifiers - Fix snmptranslate -Td output for UNITS - Fix IP address encoding issues on 64Bit architectures o snmpusm: - Usage of localized keys instead of passphrases with -Ck - New option -CE to specify usmUserEngineID (necessary to manage snmptrapd's usmUserTable) o snmpnetstat: - Skip missing entries - Don't choke on SNMPv2 PDU exceptions o snmpstatus: - Don't choke on SNMPv2 PDU exceptions o mib2c: - Misc bug fixes in some of the output styles o Perl: - Check the perl module version number against the net-snmp version - Fixes for 64bit issues - Misc other fixes o MIBs: - Updated DISMAN-NSLOOKUP-MIB.txt, DISMAN-PING-MIB.txt, DISMAN-TRACEROUTE-MIB.txt, and the IANAifType-MIB o Linux specific: - Fix compilation with ethtool - Fix Linux CPU counters on SMP machines o Misc: - Comprehensive review of in-line documentation - Make install: DESTDIR support - Many other miscellaneous bug fixes (Closes: #384367) * Delete patches applied upstream. o 5_rh9-522 o 16_man_pages_section o 17_man_pages_typo o 22_net-snmp-5.2.x-sysObjectID * Add patches o 27_gettable * Add customisation notice to README.Debian (Closes: #381451) Files: cce6186a519ce564dd443055519face9 1186 net optional net-snmp_5.2.3-1.dsc ba4bc583413f90618228d0f196da8181 4006389 net optional net-snmp_5.2.3.orig.tar.gz be92d9f94339ce7f974c0a6165d62ce8 82771 net optional net-snmp_5.2.3-1.diff.gz 093b2ade8aca38d1355e24bb29458e52 1198990 libs optional libsnmp-base_5.2.3-1_all.deb 2081c2a615dc50ae433c80fdc350fc7a 853888 net optional tkmib_5.2.3-1_all.deb 597f4d921ef80946bcce71bf2ef72781 830632 net optional snmpd_5.2.3-1_sparc.deb 6764e1b9ee04c432892035be7dd27596 923678 net optional snmp_5.2.3-1_sparc.deb 1a6568d9e60d612867fff79605c20e78 1779318 libs optional libsnmp9_5.2.3-1_sparc.deb 327a06fae992d958994371b4797e3bad 1546558 libdevel optional libsnmp9-dev_5.2.3-1_sparc.deb 4009814d497bcda8a9565c0f38daa469 916818 perl optional libsnmp-perl_5.2.3-1_sparc.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) iQEVAwUBRO3QdsP9a9GOLSE6AQLqFQf/dHyfryyFIAqSj7UaUbIb3l20GwYM+cyF tVbfNGq/28T4G77Y2sR7XOBt74ubvjpwUXa359BdtdAYNcU66TS2+niVVjVE6ZhH EkMvb88rzTjdW4RtoLDZusaOs5+ZiyAis1tT+yCgB0RhFstyfRtDRdKsDNz/8bma ald/uMFXPU+5KMvDn2EAXpe76RXEb1d+J14ng72XtDHP7kzCVzMdqSIOnJcIMlrl wkgJ71uQpwuWUSYUVe3g8oxUWo6QSv7fnp4QfajrDVL+6g8t7J+k9PC0JCQfeOgv pEb/x7r8ILLJx20MTyjVP9leLZU9+uyBa4Rk8AV+UR52LQkxMuQiLg== =+KwX -END PGP SIGNATURE- Accepted: libsnmp-base_5.2.3-1_all.deb to pool/main/n/net-snmp/libsnmp-base_5.2.3-1_all.deb libsnmp-perl_5.2.3-1_sparc.deb to pool/main/n/net-snmp/libsnmp-perl_5.2.3-1_sparc.deb libsnmp9-dev_5.2.3-1_sparc.deb to pool/main/n/net-snmp/libsnmp9-dev_5.2.3-1_sparc.deb libsnmp9_5.2.3-1_sparc.deb to pool/main/n/net-snmp/libsnmp9_5.2.3-1_sparc.deb net-snmp_5.2.3-1.diff.gz to pool/main/n/net-snmp/net-snmp_5.2.3-1.diff.gz net-snmp_5.2.3-1.dsc to pool/main/n/net-snmp/net-snmp_5.2.3-1.dsc net-snmp_5.2.3.orig.tar.gz to pool/main/n/net-snmp/net-snmp_5.2.3.orig.tar.gz snmp_5.2.3-1_sparc.deb to pool/main/n/net-snmp/snmp_5.2.3-1_sparc.deb